Explanation for maximum 1000 messages per second USB?

[JavaLaurence]

Can anyone briefly explain why the Tinkerforge architecture limits its USB bandwidth to 1000 64-byte messages per second?

[borg]

It is the maximum for USB, see chapter 5.10.2 in the USB 1.1 specification "USB Clock Model":

 

Bus Clock: This clock runs at a 1.000ms period (1kHz frequency) and is indicated by the rate of SOF packets on the bus.

 

That means, that a PC can poll a USB device with the maximum rate of 1KHz or once every 1ms.

[JavaLaurence]

Thx for the USB Spec ref (checked it.. very interesting).

 

Apart from the source code (which I'd rather not have to consult), is there any technical documentation of how Tinkerforge uses USB ? Or rather, is there any docs on the entire comms architecture (USB and Wifi)? Sorry for being so nosy.. 

[borg]

There is no documentation of the internals (except for the source code). The protocol itself is documented here: http://www.tinkerforge.com/en/doc/Low_Level_Protocols/TCPIP.html

 

The WIFI Extension speaks it directly, over USB we use the same payload as over TCP/IP.

[Nic]

Remember 1000 msg/sec is a benchmark in theory, normally an operating system has to handle callbacks, events etc. from other connected hardware devices, too.

 

TF mentioned in this matter a max frequency of around 250Hz or at least 125Hz if a robust or reliable application is needed.

http://www.tinkerunity.org/forum/index.php/topic,2253.msg14892.html#msg14892

[JavaLaurence]

I think it's quite confusing to see those low numbers when, if you don't know the internals, you'd expect a TF stack to be able to communicate at much higher bandwidth. If you hear of any device that connects via USB or Wifi to a PC, then you kind of expect that device to be able to use "the most" of those transports. It's just an expectation/surprise thing...

[Nic]

Should I remove my comments and hints to prevent any confusion on customer side ? I added links to mining the internals/explanation easier: http://en.wikipedia.org/wiki/Nyquist%E2%80%93Shannon_sampling_theorem

[borg]

@JavaLaurence: We do get the absolute maximum out of the USB protocol. If you use callbacks and configure them to 1ms and there are no other USB devices that are using the bus and your PC is fast enough you will get 1000 messages per second from one single Bricklet. More is not possible. I am not sure what you are expecting?

 

@Nic: You are confusing things. The other discussion is about the "tick_task" and calculating things inside of it. You can get the full 1000 messages per second from every Bricklet that can produce this much data (i.e. every IO Bricklet (IO4/16, Industrial DI, ...) and every Analog Bricklet (Analog In, Amient Light, ...)).

[Nic]

@borg

Well, from the customer perspective it brings me nothing if a system (OS + TF stuff) can reach "theoretically" the limits of 1000msg/sec and 1 bricklet on 1 brick as the only USB stuff in a system isnt really typical.

 

A lot of people have asked about how fast and reliable they can expect acquisition of data eg. detect encoder or scan signal if its fall or rise. I assume it could be more interesting to complement discussion by your mentioned and committed benchmark of 250hz.

 

BTW, can y give some examples in practice from last couple of month and known projects of customers where the limit of 1000msg was reached on a regular basis ?

[borg]

BTW, can y give some examples in practice from last couple of month and known projects of customers where the limit of 1000msg was reached on a regular basis ?

 

I am not sure what you mean, i just tried it out and used a Master with several Bricklets and configured a Sound Intensity Bricklet callback to 1ms. I got 1000msg/second on the first try with lots of USB devices connected to my normal work PC. It is really not hard to get 1000 messages out of a stack.

 

There are of course lots of Bricklets that can't produce this much data, but if they do it is not hard to get it transferred to the PC.

 

The other way around it works too. If you use an IO4 and toggle the value every ms you get a pretty good 500Hz signal. I have tried that several times before.