On 7/6/2011 6:02 PM, Bernd Blaauw wrote:
ftp://ftp.xs4all.nl/pub/test/10mb.bin :
1) 2.0 to 2.5MByte/second ( around 20Mbit/s, 25Mbit ISP subscription)
2) N/A , WGET not working
3) 500Kbyte/second ( around 4Mbit/s)
mTCP FTP compares poorly to the native stack and FireFox there, but FTP
is working in a very limited environment:
* The TCP/IP socket receive buffer is tiny compared to the native
network stack
* You are doing filesystem writes 8KB at a time
* You have a small virtualization penalty
* The packet interface wasn't designed for high performance; every
incoming packet requires a hardware interrupt and two software
interrupts
But for older machines, it is more than adequate. I'll try a few tests
here - I also test under VMware, VirtualBox, and DOSBox but I never
thought to compare the performance to the native TCP/IP stack.
Did you set the MTU size to 1500 in the configuration file? If you did
not, that will dramatically improve the speed.
Trying to get FTP.EXE working with WGET syntax is funny.
Limitation: servername has "//" prepended to it which ftp.exe doesn't like.
That funny URI syntax was grafted on. What exact URI are you using?
Are you adding "ftp://"; or just "//" ?
Bug: DHCP.EXE doesn't start on newline, ruining IPADDRESS parameter
(my MTCP.CFG has PACKETINT 0x60 but lacked CR/LF somehow).
Can you explain this in more detail? If you were missing a proper CR/LF
at the end of a line then the C runtime would not have recognized the
start of the next line, and that line would be effectively lost. This
happens if you use an editor that doesn't use the CR/LF convention. (I
often make this mistake when using VI under Cygwin.)
I could recognize both CR/LF and LF in the parsing code to improve
things when you are in a mixed environment. But all of the code that
reads the configuration file would have to change too, not just DHCP.
That really has the flavor of a user error.
Request:
* FTP accepting "//" in front of a servername
* DHCP starting MTCP.CFG writes on a newline
* DHCP: different errorlevels for various situations instead of
errorlevel 1 on all errors? aka "how to determine if packet driver still
needs to be loaded"
Bernd
For the first request I think that I have to look for either "ftp://"; or
just "//" to be correct. The second request might be considered a user
error. And for the third I will definitely put that on the todo list;
the error messages already indicate if the packet driver is not loaded
but I can set errorlevel too.
Mike
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Freedos-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
