Typical Timings For Various FreeEMS Processes

[Fred]

These figures are from a 32 bit Linux box with ~40% CPU usage from many many many other apps.

--------------------------------------------------------------------------------------------------------
If your figures are much slower for serial connection stuff, please, COMPLAIN!
--------------------------------------------------------------------------------------------------------
Windows users, check your buffers are 64, not 4096, and latency is 1, not 16!
--------------------------------------------------------------------------------------------------------

S19 Loading

Covers any app doing it, including FreeEMS-Loader and mtxloader. Benchmarks set with the UltimateLoader reference tool.

• Full erase: 10.7s
• Typical erase/write/verify: 15.8s (~59k image)
• Typical erase/write NO verify: 10.0s (~59k image)
• Estimated dual verify: Should be ~25s
• Estimated worse case total: ~3m to erase, write and verify (once) a full 512k image
• Ripping (full 512k always): 52.8s

Connecting

Covers any app doing it, including EMStudio and MTX.

• Interrogation ?
• Read all tunables ?
• Total: ~5 seconds for firmwares since 0.2.0-SNAPSHOT-152-g06ec3f1, longer before

Firmware Build

This will naturally vary from box to box and is much slower on windows, don't complain, your OS is broken.

• make s19 5.817s
• make clean 1.208s
• make all 13.374s - not recommended/required - always use make s19

OLV Log Loading

This will naturally vary from box to box depending upon CPU and RAM capabilities, log file size, log record size, and so on.

• Approximately 7 seconds for 180,000 std log records

I have a LOT of RAM on this box, so it's fast here.

Immediate Future

For ALL software talking to the firmware over serial: I want timings as standard output in a console.

I hope this is useful!

Fred.

[Dan]

FreeEMS Loader - S19 Loading

Erase: 15 seconds
Load: 3 - 5 minutes (varies a bit)
Rip: 10 - 15 minutes (definately varies)

Platform: Windows 7 64-bit (0-10% CPU load, very minimal loading)

EDIT: Originally I was running old firmware, had to reduce my buffer sizes from 4096 to 64 before that old firmware would work properly with emstudio. So buffers we fully reduced to 64 before I did the above timing test.

[Fred]

Yeah, that's way too long. Hopefully Sean can figure out a fix for you ASAP. Did you check those buffer settings? Please edit your post to reflect that and the settings.

[Fred]

Updated to reflect what's been proven possible by my latest code...

[Fred]

My app on windows 7 on a dual core eee in Spanish:

Code: Select all

Total bytes: 57600
Over slept total of 974
Under slept total of 4237

real    0m28.421s

What that means is that it wasn't physically possible to do it in less than 27.5 seconds, compared to 23 flat in Linux. IE, windows is slow, no surprise there. Still, not as slow as what you got, Dan!

That's with a verify. Now trying without:

Code: Select all

Total bytes: 57600
Over slept total of 2393
Under slept total of 1182

real    0m17.668s

An optimised version could get the no-verify load happening about as fast as Linux, though it's good enough in my app as is.

That's all with 64 byte buffers, however 4k buffers seemed to make little or no difference to my code. Checking now...

Buffers at 4k add 1 second for both types of load in my app.

Trying another setting that I just spotted...

no verify: 16.962s visibly faster than before...
normal load: 24.144s ditto... this is only a second off of my Linux times.

The setting to fix in Spanish is:

Opciones BM

Selecionne valores mas bajos corregir problemas de respuesta.

Temporizador de Latencia (mseg) CHANGE from 16 to 1...

This message brought to you by Fred with his typical thorough approach. We hope you enjoy the results :-)

Fred.

[Fred]

Updated again with more accurate and efficient timings from the UltimateLoader util :-)

[Fred]

Updated again! A few minor optimisations/tweaks and I've got it down to the point where I don't think it's worth chasing gains. IE, less than 0.25 second slower than possible for most tasks, 1.5 seconds on a full rip, which equates to less than 1ms average too slow on each operation. The next step in loading tech is to provide an alternative implementation which uses a little less CPU and claims those last few milliseconds back. I may never bother, though. My current setup is so close to perfect that I don't care much now. More features and a GUI interface are on the menu!