Hello,

I have a usb2 camera that uses a full BW HS ISO endpoint (3072 packet size).
It is my understanding from the USB2 doc that it is permissable to run 2
such devices through a single host controller. I got further information
from this group that MS does indeed support that configuration so long as
the devices are in fact sending full 3072 byte packets.

As I try this now, I am seeing inconsistant behavior. The hardware engineer
workng on this with me can get the two camera config running on some
computers, not on others. I cannot get it on my dev machine at all. One
camera will run fine, but the other will not. I have run the cameras
through a HW bus analyzer, both individually (so I can see only one) or
through a hub (so I can see both) and the result is similar.

Things look ok for about the first 8 frames. Then I see 57 empty Start Of
Frames (i.e. Windows is not asking it for anything) on the camera that
"fails". It then it gets another 8 frames of 3k followed by another 57
empty SOFs.

This pattern continues for some 20 or 30 cycles and then changes to one here
the device is only asked for 1k on each uFrame. It always responds with
DATA2. There are about 30 or so of these 1k uFrames and then 8113 empty
SOFs before we get back to the 1k uFrames again, then another 8113 empty
SOFs and so on.

The only notable point when running both cameras through a hub so that I
could see both on the bus analyzer was that in the starting section where
things look "ok", it appeared that instead of having two 3072 byte transfers
in each uFrame as I expected, one camera would get 8 uFrames and then the
second camera would get 8 uFrames. Eventually, I got to the 57 SOFs and the
rest of the pattern as described above. Odd.


A single camera works fine, so while this might be a driver issue, it is not
a completely obvious one.


Does anyone have any idea as to what might cause such a thing? Is there
some trick that I should be aware of regarding 2 HS Full BW ISO streams
beyond the issue that the device always send a full 3072 bytes?


Any thoughts would be much appreciated.


Best regards,


Tom Udale


PS This dual CPU Athlon 64 2400+ machine running Win XP SP1 with pretty up
to date hot fixes (certainly the big USB2 ones). I believe HC is a NEC.

I just tried the two cameras on SP2 and there is still somthing not quite
right. I am seeing the 8 good and then 57 empty SOF pattern still at the
beginning, but it does not shift over to the secondary pattern. Actually,
when run through a hub, it looks nearly right after a while. When run
individually into the motherboard, the dying camera still sees the 8/57
pattern but then it starts having trouble with the reads and does not
complete transactions correctly (I am very surprised not to see this often
actually as the camera uses and FX2 and only has a 4k fifo - with 57 missed
reads I would expect all sorts of trouble).



Regards,

Tom

"Tom Udale" <-> wrote:
Yes. Some host controllers suck. We did some USB stress tests earlier in
the year. Some controllers could sustain 45 to 50 MB/s without much
trouble. Some couldn't manage to break 30 or 35. Two max iso pipes would
be 48.

Just record the ones that don't work, and feature their names prominently
in your newsgroup postings and release notes with large red warning labels.
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

Hi Tim,





I pitched this same question over at the USB-IF developer forum and the
answer I got there (not an official USB answer but from a well known denizen
of the forum) was a little ominous. Specifically, it was noted that in
section 5.6.4 of the USB2 specification it says:

"The USB requires that no more than 90% of any frame be allocated for
periodic (isochronous and interrupt) transfers for full-speed endpoints.
High-speed endpoints can allocate at most 80% of a microframe for periodic
transfers."

It was also pointed out that a 3072 byte transfer represents 41% of a
microframe (as per table 5-5). Thus even though table 5-5 _also_ indicates
2 transfers for a 3072 byte data payload, this is at odds with the 80% value
allowable as per 5.6.4 (2*41% being 82%; although now that I look at it
more closely, there is some rounding here so it is really very borderline).
This apparent discrepancy was explained away by saying that table 5-5 only
indicates the number of transfers that are possible given the % taken up by
the data payload and that it ignores other constraints. Sigh.

So I am not completely sure what to think at this point. I have certainly
gotten the impression that people have had success (seems as if you had some
success) with 2 HS Full BW ISO endpoints running on a single host controller
in some instances. However, it is not clear to me at this point that host
controllers that allow that are not operating somewhat outside the USB
spec - or said another way, it would appear thus far that host controllers
that allow only one are entirely within the spec in spite of how annoying
that is to me for my application and how borderline this 82% value is.

I guess it makes sense to take the pragmatic tack here: the spec is
ambiguous. Some HCs support it and some don't. In the cases that don't, we
will simply have to get a second HC.

Thanks for the reply.

Best regards,

Tom

"Tom Udale" <-> wrote:
One very plausible answer to this problem is to switch to a bulk pipes. The
fact is that USB 2 nearly makes isochronous pipes obsolete. Many of the
capture devices we're doing now use bulk pipes.
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

Tim,

I was pondering this as I was struggling with this silly 80% rule. Given
the number of times I have actually seen bus errors using the ISO pipes
(that would be zero) it does seem as if they may be more or less equal in
practice: error free and periodic because there are no errors.

How often to you see retries with the bulk pipes? Never?

Tom

"Tom Udale" <tom@tom.com> wrote:
When we have looked, we've never seen any. In steady state, I'm not sure
we would know. Even with 2x 25MB/s cams running full out, there's still a
bit of headroom left to cover that.

The one disadvantage is that there is no automatic gating to prevent the
user from plugging in 4 or 5 cams He'll just see 5 images performing
poorly. That's more of a "release notes" issue than a technical issue.
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.