rules of thumb: data transfer speeds

Fred Hawkins

I've read the manual a bit, and the forum a bit, and I haven't seen a speed of transfer estimate for cog/hub data. I have seen the clock synch number 7 .. 22, but it doesn't resolve for me. What I want to know (and have) are·mental rules of thumb:·xxx numbers of bytes or words or longs in a second.

It would be nice to have that broken down by spin/assembly/what-have-you if there's a difference.

I'm not asking for data for optimized assembly in multiple cogs (though that's a nice benchmark) as much as your run of the mill i/o measures.

And while we're at it, how about the same through the propplug, an sd card and the two eeproms.



·

Bergamot

Well, in the worst case scenario (22 clock cycles for every 4 byte access), it takes 5362 clock cycles for one kilobyte. Best case is 1792.

If you have 80,000,000 clock cycles per second, you can do about 14MB/second in the worst case, and 44MB/s in the best case, if my math is correct.

Mike Green

Fred,
The PropPlug and other USB to serial adapters are limited as much by the drivers used, USB latency, and generally what's on the other end of the cable. The FullDuplexSerial Propeller driver has been tested around 230KBaud. That's bidirectional on a serial port. Theoretically, asynchronous serial could run over 1MBaud with a half duplex driver, but I'm not sure it's actually been done.

SD card I/O is so dependent on the specific SD card involved and on the layout of the data on the card, that I'm not sure your question is meaningful as a general case. Rokicki has some SD card timing test programs, but the information would be valid only for a specific SD card.

EEPROM speed again depends on what you're measuring. There are two I2C bus speeds ... 100KHz and 400KHz. There are some parts that will function at 1MHz, but again that depends on the particular manufacturer and part. Mixing parts on the same bus affects the overall bus speed. Effective speed depends on whether you're doing sequential access or random access. Write speeds depend on the page size which depends on the manufacturer and part and, when the address has to cross a page boundary, there's a variable amount of write time on the order of 5-10ms.

Paul Baker

Bergamot those figures are off. First off the only real measure is for assembly, Spin operating in the hub memory, it must make several hub accesses for each instruction. 16 cycles is the fastest a sustained access to the hub takes in assembly, at 80/16, thats 5 Million longs per second, or 20 MBps. But this measure has very little meaning, the actual troughput depends on how your code. To get the highest speed you have space for 2 instructions between each access, enough to do a loop and increment either the hub pointer or cog pointer but not both or any processing of the data. If you want to know what a real world application throughput is, record the value of cnt, perform your code then take the cnt again, the difference between them is the number of cycles the code took to execute, then use that as a measure to calculate what your data throughput is.

As far as the accessing of external things, thats it's own ball of wax, and isn't directly related to hub accessing. Refer to Mike's post for that information.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.

Post Edited (Paul Baker (Parallax)) : 7/20/2007 5:49:55 PM GMT

CJ

couldn't you use the beginning of cog ram for your buffer and read from hub ram high to low using a DJNZ for your loop and cog pointer, and decrement your hub pointer rather than increment it?

essentially doubling your usable hub transfer speed

just start your code with a JMP and then your cog buffer, then your main code

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Parallax Forums - If you're ready to learn, we're ready to help.

Fred Hawkins

Mike Green said...
Fred,
The PropPlug and other USB to serial adapters are limited as much by the drivers used, USB latency, and generally what's on the other end of the cable. The FullDuplexSerial Propeller driver has been tested around 230KBaud. That's bidirectional on a serial port. Theoretically, asynchronous serial could run over 1MBaud with a half duplex driver, but I'm not sure it's actually been done.

SD card I/O is so dependent on the specific SD card involved and on the layout of the data on the card, that I'm not sure your question is meaningful as a general case. Rokicki has some SD card timing test programs, but the information would be valid only for a specific SD card.

EEPROM speed again depends on what you're measuring. There are two I2C bus speeds ... 100KHz and 400KHz. There are some parts that will function at 1MHz, but again that depends on the particular manufacturer and part. Mixing parts on the same bus affects the overall bus speed. Effective speed depends on whether you're doing sequential access or random access. Write speeds depend on the page size which depends on the manufacturer and part and, when the address has to cross a page boundary, there's a variable amount of write time on the order of 5-10ms.

Thanks, Mike.

I'll take the USB for 230K baud, or even the 50K baud. That I can understand.

I don't understand about SD cards -- what's the range of differences between cards? And what is the range of data layouts on a card? (How about a rule of thumb·that says, "don't do that that way because it'll be SLOW", or·"keep it to fat16", say, because the object doesn't know anything else?)

On eeproms, I was thinking that they came in two flavors, the little one in the PropDemo and EdKit, and the big one on the ProtoProp. So let's ask,
what's the nominal speed of sequential page size reads through the boot up pins?

As I understand it, the cog has to take the data serially, assemble it to·the certain length --·byte, word, long -- and rather quickly dump it to hub memory. And further, if I read you and Paul correctly, both cog speed and hub memory access is fast enough to keep up with any of these storage devices. Though maybe only in assembly, implied by Paul.

Maybe what I am asking for is a benchmark thread. Such and such speed using this specific·object on this hardware arranged this way.

Which is, in my case, the rookie·EdKit with an SD card. And no software to speak of. Just a mess of contradictory questions. Maybe I'll just go eat worms. Or pound sand. Or finish·Methods and Cogs·and get on with it.

___

Paul,

I take your point to be, "get it to work, measure it yourself, and here's how."·And I get the feeling that Spin is to slow to bother with even for non-time critical stuff when it comes to mass storage data.

Fred

Paul Baker

Fred I somewhat misundertood the aim of your question, yes for any mass storage device the "device driver" portion should be written in assembly.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Paul Baker
Propeller Applications Engineer

Parallax, Inc.