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
On Apr 28, 2019, at 2:54 AM, hong_zhong wrote:
>
> 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?
Hang on. Are you saying this a UVC camera? If so, then why do you have a driver at all? The WHQL specs require that a UVC camera be driven by usbvideo.sys alone.
Even if you have chosen to have your own private side channel for out of band information, it should have been done as a bulk endpoint. Your 490-byte payload would fit into one single bulk packet.
I’m going to repeat what I’ve said several times. Your device has a design flaw. You are using the control pipe in a way that it wasn’t designed for. Because of that, you have triggered behavior that was never expected to be a problem. I do not doubt that the root issue is scheduling within the Windows 7 EHCI driver, but THAT BEHAVIOR IS NEVER GOING TO BE CHANGED. The only way you can fix this problem is to change your device to transmit these blocks over a bulk endpoint.
—
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.
@Tim_Roberts said:
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?
I use hardware bus analyzer?
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.
Yes, i see send request ,receive 64, send request ,receive 64 etc, like this:
IN packet
Data1 packet
Ack packet
IN packet
Data0 packet
Ack packet and etc
but this doesn’t take too long. in our protocol. Time is consumed between different packages.
send request packet (include flash address and offset)
9 SOF
receive device data ( 490 bytes ,include header) // this doesn’t take too long
7 SOF
send request packet (include flash address and offset)
9 SOF
receive device data ( 490 bytes ,include header) // this doesn’t take too long
7 SOF
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.
@Tim_Roberts said:
On Apr 28, 2019, at 2:54 AM, hong_zhong wrote: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?
Hang on. Are you saying this a UVC camera? If so, then why do you have a driver at all? The WHQL specs require that a UVC camera be driven by usbvideo.sys alone.
No, this is a private protocol camera, but I use the uvc protocol camera for comparison.
Even if you have chosen to have your own private side channel for out of band information, it should have been done as a bulk endpoint. Your 490-byte payload would fit into one single bulk packet.
I’m going to repeat what I’ve said several times. Your device has a design flaw. You are using the control pipe in a way that it wasn’t designed for. Because of that, you have triggered behavior that was never expected to be a problem. I do not doubt that the root issue is scheduling within the Windows 7 EHCI driver, but THAT BEHAVIOR IS NEVER GOING TO BE CHANGED. The only way you can fix this problem is to change your device to transmit these blocks over a bulk endpoint.
yes, you are right, Recently we add a requirement and need to read a big data （about 200k to 500k）, if we change to bulk transfer, the device firmware need to change,and the protocol need change.
—
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.
@“Peter_Viscarola_(OSR)” said:
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
thank you peter， Now I want to see if there is any way to solve this problem. Recently we add a requirement and need to read a big data (about 200k to 500k), because of change to bulk ,our device fireware need to change, and the protocol also need change.