Benchmark network speed

Page 3/3
1 | 2 |

Par ducasp

Champion (392)

Portrait de ducasp

14-10-2020, 12:57

S0urceror wrote:

uIP on the MSX rocks.

With the TCP/IP checksums done in assembly instead of C I now get 11.113 bytes per second. A 60% improvement vs my initial measurements via Internestor Lite (INL).

Measurement is done by downloading BRUNILDA.ROM (1.277.952 bytes) in 115 seconds on my 3.58 MHz NMS8250 MSX2. Pretty impressive for a software based TCP/IP stack running on our trusted Z80.

uIP is a C-based IP stack that I compiled with the latest SDCC. uIP is statically linked into the client app. This makes the application around 22k bigger but it does everything in the main loop. During events callbacks are called to do something with received data or to handle errors. No dependency on reserved segments in memory mapper, background processing and interrupts. No INL, no UNAPI. Simple and straightforward.

I guess I can tweak it a bit more here and there but I'm satisfied with the results so far.

P.S. I'll put up the sources later this weekend. Then I'll start playing with the other clients like HUB and TELNET.

Hi Sourcer0r,

Wouldn't it be possible to make a INL uIP based to reap the benefits for all adapters using INL as well as keeping compatibility with UNAPI? I mean I don't mind anyone picking up Telnet or hubg code and adapting to different interfaces, just that for the users in general it might be better to have a single version and not think about grabbing special versions of each software... (perhaps if the special version works for Obsonet that is quite cool, but still might leave users waiting for specific versions of software to be released)

Anyway, I'm curious on Telnet with uIP embedded, as I've been quite a bit lazy with memory management on it and perhaps you can figure out some issues I had when trying to have close to 50KB of RAM used, never got to debug that properly to figure out if it is a sdcc issue or any bug in my code or in the msx2ansi library Tongue

Par ducasp

Champion (392)

Portrait de ducasp

14-10-2020, 14:31

Another question is, what is the performance bump when saving to disk? That is an interesting metric to get to understand the system better and what are the benefits of this performance increase on the end result. By the way, great work on squeezing that performance out of a TCP IP stack running on z80, it is quite impressive. Wink

Par S0urceror

Master (140)

Portrait de S0urceror

18-10-2020, 23:14

ducasp wrote:

Wouldn't it be possible to make a INL uIP based to reap the benefits for all adapters using INL as well as keeping compatibility with UNAPI?

The beauty of uIP is it's simplicity. Everything runs in one main thread. With 1 tiny send/receive buffer. The moment a packet arrives it is immediately processed. Bundled with uIP are 'apps' that perform higher level functions like resolv, dhcp, http-get, http-server, etc. These apps are linked into the main-loop and fire off callback functions when something interesting happens. Similar to node-js does. This all compiles to a 40k MSX DOS executable which runs without memory-mapper on a 64KB MSX.

INL runs as a TSR hooked to the interrupt. There is at least a 1/50th or 1/60th delay before a packet is processed. Packets are read via ETHERNET UNAPI calls from a lower-level driver. They are put in circular buffers which are read by a client like TELNET via TCP/IP UNAPI calls. All these UNAPI calls go via a chain of EXTBIOS calls. You need a memory-mapper with at least 2 free pages.

Long story short, it is possible to create a uIP/INL combination but it is a lot of work (TSR/UNAPI/Paging) and I'm not convinced if it will in the end be a lot faster in this way.

What I can do is to create an interface C file like UnapiHelper.c that calls directly into uIP. You can then easily build a statically linked uIP version of your clients without any change to the rest of your code. This way UNAPI is skipped and you interface directly with uIP.

Page 3/3
1 | 2 |