I test my usb driver （usb2.0），use control transfer ，read 200k data，in win7， need 1300ms， but in win10， only need 200 ms，What is the problem?
- Do the both OSes run on the same hardware?
- If so check in Device Manager the USB controller to which your device is attached under both OS.
Get a bus analyzer, get a trace.
1.3 seconds is ridiculously long. Something isn’t right.
Peter
hong_zhong wrote:
I test my usb driver （usb2.0），use control transfer ，read 200k data，in win7， need 1300ms， but in win10， only need 200 ms，What is the problem?
What are you measuring here? From what event, to what other event? And
how are you measuring that time? High-speed device or full-speed device?
Control transfers have NEVER been a good way of transferring large
blocks of data. You should have used a bulk endpoint for this. The
control endpoint has a very small packet size (typically 64 bytes), so
your transfer gets chopped up into thousands of small packets, which
then have to be scheduled. The control pipe packet sequence is not as
efficient as the other types, so they take more bus time. Only a small
percentage of each frame is reserved for control transfers; beyond that,
you’re competing with all of the bulk pipes. If you have a large USB
disk transfer or a web cam stream, your control transfers will get
pushed aside.
What I’m saying is that, although 1.3s is a long time, I’m not terribly
shocked.
Dear ALL :
I install win10 64bit and win7 64bit in the same computer, and the device is the same. I use usb analyzer , in win7 64bit system, transfer 200k data, need 1300 ms, the device is hight-speed device.
because the software architecture is use control transfer set param, so i need solve this problem. i read the data in the init function, at this time ,the bulk endpoint not thansfer data.
On Apr 25, 2019, at 11:35 PM, hong_zhong wrote:
>
> I use usb analyzer , in win7 64bit system, transfer 200k data, need 1300 ms, the device is hight-speed device.
But what are you measuring? From the start of the first control packet to the end of the last? Your transfer would require about 3,000 packets. So, are you actually seeing one control packet every 3 or 4 microframes? So there is a 400ms gap between control packets? Or is the response taking longer? Tell us some of the detailed timing here.
> because the software architecture is use control transfer set param, so i need solve this problem. i read the data in the init function, at this time ,the bulk endpoint not thansfer data.
I understand. I’m telling you that your device has a design flaw. It should not have used the control endpoint for this function. That was a mistake, and this is why. There might not BE a solution for Windows 7. No one at Microsoft is doing any new development on Windows 7.
—
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.
in win 7,the usb analyzer capture: Record : 9 SOF in each transfer, and in win10 ,is 2 SOF. I want upload a picture,but not success.
On Apr 25, 2019, at 11:53 PM, hong_zhong wrote:
>
> in win 7,the usb analyzer capture: Record : 9 SOF in each transfer, and in win10 ,is 2 SOF.
Do you mean request, then response, then 9 SOF? Or do you mean request, then 9 SOF, then a response? Do you see the difference?
> I want upload a picture,but not success.
You get success, but it just takes a long time. Right? As I said, it’s entirely possible that you may have to live with it. No one is going to rewrite the USB scheduling code for Windows 7 at this point.
The control endpoint was never designed for transferring pictures.
—
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.
I install win10 64bit and win7 64bit in the same computer, and the device is the same.
You didn’t answer second question.
Start-of-Frame Transactions —the beagle protocol analyzer
Start-of-Frame ( SOF ) transactions are issued by the host at precisely timed intervals. These tokens do not cause any device to respond, and can be used by devices for timing reasons. The SOF provides two pieces of timing information. Because of the precisely timed intervals of SOFs, when a device detects an SOF it knows that the interval time has passed. All SOF s also include a frame number. This is an 11-bit value that is incremented on every new frame.
SOFs are also used to keep devices from going into suspend. Devices will go into suspend if they see an idle bus for an extended period of time. By providing SOF s, the host is issuing traffic on the bus and keeping devices from entering their suspended state.
Full-speed hosts will send 1 SOF every millisecond. High-speed hosts divide the frame into 8 microframes, and send an SOF at each microframe (i.e., every 125 microseconds). However, the high-speed hub will only increment the frame number after an entire frame has passed. Therefore, a high-speed host will repeat the same frame number 8 times before incrementing it.
i read 490bytes include packet header each time , I find in win7 read each packet, have 16 SOF, and in win10 only 3 SOF.
hong_zhong wrote:
i read 490bytes include packet header each time , I find in win7 read each packet, have 16 SOF, and in win10 only 3 SOF.
I am not making myself understood.
A control endpoint has a maximum packet size of 64 bytes. You can do
larger transfers from your driver, but the host controller driver will
chop them up into packets of 64 bytes each. In your case of a 490-byte
transfer, that will be 8 packets.
Each of those packets consists of three stages. First, the host sends a
packet with the setup information (request type, request, value, etc).
Then, the host asks the device to send back its reply, and the device
sends a response. Then, the host send an acknowledgement to the
device. These are called the setup, data, and status stages.
So, one possibility is that your device responds quickly, so we see the
three stages complete right away, and then there is a long delay before
the next setup. That would be an operating system or driver issue. The
other possibility is that your device simply takes a long time to
respond, so we see setup and data right away, but the data phase keeps
getting a NAK because the device isn’t ready. That’s not an operating
system issue. Your bus analyzer ought to be able to show you that detail.
If it is an operating system issue, so that there is a long gap between
the completion of one packet and the start of the next, then as I said,
it’s likely there is nothing you can do. You will have to live with
it. Either that, or move to Windows 10.
@Tim_Roberts said:
hong_zhong wrote:i read 490bytes include packet header each time , I find in win7 read each packet, have 16 SOF, and in win10 only 3 SOF.
I am not making myself understood.
I mean in win 7 ，between send request packet and then receive device data， have 9 SOF , then send the next request packet , have 7 SOF,like this:
- send request packet
- 9 SOF
- receive device data ( 490 bytes ,include header)
- 7 SOF
- send next packet
- 9 SOF
- receive device data ( 490 bytes ,include header)
- 7 SOF
but in win10， is like this。
- send request packet
- 2 SOF
- receive device data ( 490 bytes ,include header)
- 2 SOF
- send next packet
- 2 SOF
- receive device data ( 490 bytes ,include header)
- 1 SOF
I use usb logic analyzer in win10 and win7， find everything except SOF is the same.
A control endpoint has a maximum packet size of 64 bytes. You can do
larger transfers from your driver, but the host controller driver will
chop them up into packets of 64 bytes each. In your case of a 490-byte
transfer, that will be 8 packets.
yes, you are right . the host controller chop them to 8 packets.
Each of those packets consists of three stages. First, the host sends a
packet with the setup information (request type, request, value, etc).
Then, the host asks the device to send back its reply, and the device
sends a response. Then, the host send an acknowledgement to the
device. These are called the setup, data, and status stages.
yes. you are right.
So, one possibility is that your device responds quickly, so we see the
three stages complete right away, and then there is a long delay before
the next setup. That would be an operating system or driver issue. The
other possibility is that your device simply takes a long time to
respond, so we see setup and data right away, but the data phase keeps
getting a NAK because the device isn’t ready. That’s not an operating
system issue. Your bus analyzer ought to be able to show you that detail.
in win 10 and win7 , the device is same ,and use usb logic analyzer , the packet is same. （NACK and ACK）
If it is an operating system issue, so that there is a long gap between
the completion of one packet and the start of the next, then as I said,
it’s likely there is nothing you can do. You will have to live with
it. Either that, or move to Windows
so i am not sure it is an operating system issue. I test in win8 ,it like win10, it’s ok.
@SweetLow said:
I install win10 64bit and win7 64bit in the same computer, and the device is the same.
You didn’t answer second question.
the same computer, and the same usb port, and the same device.
the driver code is same.
On Apr 27, 2019, at 7:52 PM, hong_zhong wrote:
>
> I mean in win 7 ，between send request packet and then receive device data， have 9 SOF , then send the next request packet , have 7 SOF,like this:
>
> * send request packet
> * 9 SOF
> * receive device data ( 490 bytes ,include header)
> * 7 SOF
> * send next packet
> * 9 SOF
> * receive device data ( 490 bytes ,include header)
> * 7 SOF
Are you using a hardware bus analyzer or a software one? Because that’s NOT what the bus traffic will look like. As I said, there will be 8 different request and receive cycles to satisfy your request. You should see send request, receive 64, send request, receive 64, send request, receive 64, etc., finally followed by a receive of 42. The fact that you mention 9 SOFs suggests that you’re getting one packet per frame on Windows 7.
But, repeating what I said before, it is what it is. You can’t change the timing without switching to a bulk pipe.
—
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.
Is it possible that the control endpoint on win7 is full speed?
@hong_zhong said:
Is it possible that the control endpoint on win7 is full speed?
win 7 is in high speed。
Full-speed hosts will send 1 SOF every millisecond. High-speed hosts divide the frame into 8 microframes, and send an SOF at each microframe (i.e., every 125 microseconds).
I found that the uvc protocol is the same， so i think it not our driver problem， it is an operating system issue? is the usb controller driver issue?
Are you using a hardware bus analyzer or a software one?
Please answer Mr. Roberts question.
i think it not our driver problem
Is that all this is about? Because, if so, it’s almost certainly not your drivers problem. We can be quite sure of that. All the rest of this thread is noise, if that’s all you care about.
Peter