Re: Cause of Dropped HS ISO Packets?

Tech-Archive recommends: Fix windows errors by optimizing your registry

Sibi,

Ok. I have discovered the source of the error on the machine that was suffering from a blizzard of USBD_STATUS_ISO_NOT_ACCESSED_BY_HW errors. It turns out that there a bad interaction resulting from a 32 bit PCI card being plugged into a 64 bit PCI slot (BIOS problem maybe??). In fact any 32 bit card plugged into that slot caused USBD_STATUS_ISO_NOT_ACCESSED_BY_HW errors all over the place.

Now I am going back over all the 3 host controllers in that machine and re-evaluating their behavior in light of this discovery.

Some are completely flawless with regard to the USBD_STATUS_ISO_NOT_ACCESSED_BY_HW error. Others are still exhibiting it but _much_ less frequently.

With regard to your suggestions below, I have tried a some things and have some comments:


1. The documentation is very confusing with
USBD_START_ISO_TRANSFER_ASAP. I have had long painful experience with
that expecially with vista, but now I can I vouch that
USBD_START_ISO_TRANSFER_ASAP works fine inside IO completion.

I am glad I am not the only one confused by that. I am going to try tomorrow to switch back to ASAP for all scheduling and see if that improves anything (particularly given my comments further below). I get the impression ASAP is the most common technique and if there is any rule of thumb one can surely follow with this sort of thing it is "follow the common technique".


2. Why do keep increasing the URB insteads of the packets. e.g you
increased form 10 to 50. I think you are not able to catch the cause
because of your restriction to 8(32) packets and not adventuring to
experiment with more. I would suggest increasing the packets and
decreasing the URB's

Again, this was for a latency reason. In the interest of solving this problem however I did increase my packet count to 256 as you suggested. I have found however that in the current cases of USBD_STATUS_ISO_NOT_ACCESSED_BY_HW, this has no impact at all. Indeed on the HC that runs flawlessly, I am using my original 10 URBs with 8 packets each and I cannot get it to fail.


3. I/O completion routines are unpredictable in time and the more you
que them the more latent and bigger their delay variance would be I
beleive.

4. Have you tried getting the time stamp of your completion routines
(either by toggling a parrallel port pin or "rdtsc" instruction and
writing to debug port - use firewire; RS232 is depreciated for these
sort of high bandwidth debugging). I am sure you would be able to see
a glaring problem.

Yes, I have done this in the past and I was actually pretty impressed with how consistently the completion routines were called. I was looking at it on a scope using parallel port bits and was getting a quite consistent 1kHz with 8 packets per URB. As you mention of course there were some big delays in there occasionally, but by and large it was very good. Your experience versus mine may well be a case of "your mileage may vary".

5. You want to signal to your application (i assume using an event)
after 8 packets or every 1mS. That is unrealistic in windows. From my
experience 8mS or more is realistic? You might want to recalculate
your urb->UrbIsochronousTransfer.NumberOfPackets from there.

Certainly hoping for a worst case of 1mS is extremely unrealistic. But I pretty regularly run 1kHz callbacks in windows (both from a Timer/IO card interrupts and from the USB completion routines) and I usually see pretty predicable results. In addition, this particular application is on a controlled system where I have a good amount of input on the other running tasks.




One thing that did occur to me regarding URB scheduling and so-forth is that scheduling a URB with the HC driver is not the same as actually having it scheduled with the HC. It is simply scheduled with the driver. Thus I thought before I found the 64bit PCI slot problem that perhaps I was taking too long in my completion routine and that the HC driver was unable to pull the pended URB out of its list and actually write it into the HC hardware in time for it to be used. Is this a rational analysis? Is it possible to cause USBD_STATUS_ISO_NOT_ACCESSED_BY_HW by sitting in the completion routine too long (particularly when using small packet counts)?


For the record, I modified my driver to be able to bypass all processing in my completion routine and simply reschedule the URB as a test of my analysis. For each HC that exhibits the occasional USBD_STATUS_ISO_NOT_ACCESSED_BY_HW error, I now try NOPROCESSING and num packets = 256 to see if it goes away. In no cases yet has that made any difference at all.

It is for this reason that I am now going to go back and try using always ASAP - the thinking being that specifying StartFrame is just asking for trouble.


Best regards,

Tom
.

Relevant Pages

  • Re: Rate Monotonic Scheduling (RMS) vs. OS Scheduling
    ... anothe in house scheduler algorithm) or using the OS scheduling. ... "dynamic control" layer is responsible for handling protocols' control ... duration and deadlines in advance. ... Of course this only applies after packets have been received. ...
    (comp.arch)
  • Re: bulkusb sample
    ... You can send an URB for virtually any transfer size. ... The host controller will ensure that the packets sent over the wire are not more than the endpoint's MaxPacketSize. ... Now, my guess is that your device is full speed and not high speed, in which case 64 bytes for MaxPacket makes sense. ... The maximum packet size of a pipe is specified in the USB ...
    (microsoft.public.development.device.drivers)
  • Re: gigabit+bonding = no performance improve ?
    ... Linux bonding does offer the prospect of doing round-robin scheduling ... The scheduling of packets for inbound to the backup server ...
    (comp.os.linux.networking)
  • Re: [PATCH] usb bulk transfer: 1024 byte packets
    ... The transfer size in the URB is not limited by the maximum packet ... The HC driver splits up the transfer as specified by URB into ... the required number of packets. ...
    (Linux-Kernel)
  • Re: [PATCH] usb bulk transfer: 1024 byte packets
    ... byte packets in bulk transfer mode (despite the hard limit of 512 ... created a kernel patch which allows the use of 1024 byte URBs, ... The transfer size in the URB is not limited by the maximum packet size. ... to discuss the specifics of what it mean "devices insisted on 1024". ...
    (Linux-Kernel)