RE: next USB issue

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

From: Daniel Miller (gorlash_at_community.nospam)
Date: 03/05/05 

Date: Fri, 04 Mar 2005 16:21:21 -0800

Well, first of all, IgnoreHWSerNum had been suggested in order to solve
the problem of finding physical slot positions of the device, not to
solve this current problem, which is the very long detection time for
Windows. It did *not* solve the slot-position problem, as it turned out,
and I ended up solving that problem a different way.

The problem I have now, is the amount of time it takes Windows to
enumerate all my devices, before my application can begin interacting
with them. Please re-read my original message below, which describes my
problem in detail. Is the IgnoreHWSerNum option relevant to this issue
in some way?? If so, please clarify how it would aid me with this??

            Dan Miller

martinbo@online.microsoft.com ("Martin Borve [MSFT]") wrote in
news:CnhbvORIFHA.1328@TK2MSFTNGXA02.phx.gbl:

> Dan,
>
> I believe previously you had mentioned using the undocumented
> IgnoreHWSerNum registry flag. Did this not work for you?
>
> Thanks,
> Martin Borve [MSFT]
> This posting is provided "AS IS" with no warranties, and confers no
> rights. Attachment decoded: untitled-2.txt
> ------=_NextPart_0001_2ABA3AD4
> Dan,
>
> I believe previously you had mentioned using the undocumented
> IgnoreHWSerNum registry flag. Did this not work for you?
>
> Thanks,
> Martin Borve [MSFT]
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>
> Attachment decoded: text-x-rtf-3
> ------=_NextPart_0001_2ABA3AD4--

I've tentatively asked about this previously, but I need to discuss it
more concretely now... We are developing a 12-slot bulk USB tester.
This previously ran under linux, now we're porting it to windows. Under
linux, the total cycle time for a typical factory-format/write-verify-
test/write-dos-format cycle was 60-90 seconds, running 12 devices in
parallel (depending on device size). Power-up takes about 10 seconds of
that, *2 because we have to cycle power after factory format.

Now, under Windows, I'm finding that the time to power up 12 parts is 60-
70 seconds, if the device serial numbers are not known to Windows (and
they usually won't be). So we power up the parts (60-70 secs), run the
factory format (which assigns the usb serial numbers), cycle power (oops,
another 60-70 secs), then run the other tests. We are going to be
looking at 180-210 seconds per cycle now. This is *not* going to be
acceptable to our customers... they are already running multiple shifts
to get all their devices manufactured.

So what options do I have wrt speeding up Windows' power-up device
handling?? Right now I'm running a user-space application which
communicates with the devices using DeviceIOControl and the SCSI
interface. Would writing a device driver give me any options to improve
this cycle?? Would I have to completely remove the Windows USB drivers
and substitute my own? Or maybe do something to just make USB drives
*not* be PnP devices, so Windows doesn't have so much work to do??
*Please* give me some advise on my options here. Thanks!!

Relevant Pages

  • next USB issue
    ... We are developing a 12-slot bulk USB tester. ... because we have to cycle power after factory format. ... Now, under Windows, I'm finding that the time to power up 12 parts is 60-70 ...
    (microsoft.public.development.device.drivers)
  • Re: kern/60889 - zero IP id change issues in 5.2RC2
    ... > No need for monotonic increase, it's a nonce and can cycle in any order. ... > I suspect Windows VJ compression is easiest to get going with PPP ... > on the connection, as TCP options defeat VJ compression. ...
    (freebsd-net)
  • Re: virus help
    ... The pass this cycle, please follow the steps: ... > Repairing Windows XP: ... > Windows XP firewall or use a third-party firewall (like ... > reinstall to download the updates. ...
    (microsoft.public.windowsxp.help_and_support)
  • Re: time.clock() or Windows bug?
    ... time.clockuses QueryPerformanceCounter under windows. ... the operating system actually synchronized the cycle ... (The cycle counter is, after all, a writable register.) ...
    (comp.lang.python)
  • Re: time.clock() or Windows bug?
    ... time.clockuses QueryPerformanceCounter under windows. ... On a multiprocessor computer, it should not matter which processor ... the operating system actually synchronized the cycle ... (The cycle counter is, after all, a writable register.) ...
    (comp.lang.python)