Op 7-7-2011 1:32, Michael B. Brutman schreef: > 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
I'm happy with whatever I can get. My real hardware has an Nvidia chipset network driver for which no packet drivers exist, so sticking to virtual machines. I wonder if any PCI (or even PCI-express or onboard) network cards still support packet drivers. 8KB filesystem writes? odd. So it's: 1) download/transfer 8KB (8KB transfer buffer) 2) halt download, dump transfer buffer to disk and clear it 3) continue downloading. Easier at least compared to having a 8KB transfer buffer plus a 'huge' receive buffer (nearly size of all of machine's conventional memory, a multiple of 8KB?) followed by only clearing the buffer if it's full or a file has been downloaded completely (whichever comes first). Your single buffer might be more efficient compared to transfer buffer plus receive buffer. Or perhaps I should stay silent hehe, failed miserably while learning about OSI layers and TCP/IP. > 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. It's more than adequate indeed, I'm not complaining hehe. Only wanted to start out by eliminating slow servers as potential bottleneck. The listed ftp://ftp.xs4all.nl/pub/test/10mb.bin should be same for everyone as it's intended by that ISP for speedtest purposes. > Did you set the MTU size to 1500 in the configuration file? If you did > not, that will dramatically improve the speed. Yep, did so. > That funny URI syntax was grafted on. What exact URI are you using? Are > you adding "ftp://"; or just "//" ? FreeCOM (maybe also MSDOS command.com or 4DOS) seem to split arguments at the "/" level. See the "FOR LOOP" in my batchfile, with batchfile called as: ftp.exe ftp://ftp.xs4all.nl/pub/test/10mb.bin resulting in: ftp.exe //ftp.xs4all.nl (on which it chokes, not knowing how to handle //). Basicly there are 2 options: 1) find a way to strip the prepending "//" before feeding to FTP 2) allow FTP to accept them and strip it themselves, requiring code changes. >> 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.) Using mostly NOTEPAD in Windows, or ECHO bla > output.txt in DOS. DHCP writes everything on newlines (as expected) except the first line it writes (ip address). I don't know if there's any solution except maybe writing a space, then start on newline. Best case you get an empty line in between, worst case no empty line but still working. > 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. Yeah easier to have a batchfile do ECHO PACKETINT 0x60 > %mtcpcfg% > 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. I don't mind if it's // or ftp.exe you look for, all it results in is me having to do either: * "FTP %1%2 < input.txt" (in case of checking for ftp://) * "FTP %2 < input.txt" (in case of checking for //) For DHCP I can imagine various errorlevels for different reasons: * missing MTCPCFG variable * MTCPCFG variable points to non-existing file * missing PACKETINT keyword in file * unable to write to MTCPCFG file (yay hidden/readonly) * packetdriver not loaded yet * static config found in MTCPCFG file * time out (no DHCP server found) * what else? invalid MTU size? Bernd ------------------------------------------------------------------------------ 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
