From: Eric A. <eric@CoLi.Uni-SB.DE> - 2007-12-26 17:30:42
|
Hi Marton, CCing the kernel list about this issue... Merry Xmas everybody :-). > the FreeDOS PC it is painfully SLOW! (100kb/sec) How fast is it with other DOS? > 1) If I connect FROM the FreeDOS PC to the other PC to copy the files, > it flies! (~3MB/sec) Wow, that is a lot better :-). > 3) If I copy the files to a RAM Drive instead of, say the drive C:, > it flies also so I believe that > a) FreeDOS has some ... issue writing to the hard-disk "in background" > (which is what happens when you copy files from another PC to it) Maybe you tried this on a large fat32 disk? I think our FAT writes can be pretty slow in such a context. You can also try using a delayed-write cache. LBAcache does not delay writes. It might also help to first set the file size to the final size without actually filling the contents yet. If you want to experiment with that, I could make a modified XCOPY for you, so you can compare local XCOPY speed of normal and modified XCOPY versions :-). To get a small write improvement, try the udma/udma2, xdma, qdma or uide driver from Jack (whichever version is online at the moment) and enable the write overlap. That means that DOS can already do other stuff after sending the data to the disk, without waiting for the okay from the disk. For real delayed / pooled write caching, try DR DOS nwcache or a shareware cache like the ones mentioned as "delayed write" or "write combine" in caches.txt in docs/lbacache/ :-). Those are: Quickcache, Hyperdisk, Ccache, I_Cache. If one of those makes writing significantly faster with MS Client, I would be very happy if you could help me with some experiments! Let me know if you have problems to find those caches online... > If I do ANY operation to the disk, say, read a directory for example, I > get a "PANIC: more than two near fnodes requested at the same time!" Hmmm I did not know that you are supposed to be allowed to do several file operations simultaneously. You cannot disable the warning, you have to provide more near f_nodes ;-). Otherwise you get unpredictable results. You will have to change only two places... get_near_f_node() in fatfs.c, change to, for example: f_node_ptr get_near_f_node(void) { int n = 0; f_node_ptr fnp = fnode; while (n<4) { if (fnp->f_count == 0) { fnp->f_count++; return fnp; } fnp++; n++; } panic("more than 4 near fnodes requested at the same time!\n"); return (f_node_ptr) 0; } You also have to change the last 2 lines in globals.h, in the SDA: GLOBAL struct f_node fnode[4]; GLOBAL int fnode_fd[4]; I guess that MS Client would be supposed to swap out the SDA or to avoid kernel reentrancy by just not calling the kernel while the kernel is already busy. But I do not know any technical MS Client details so giving FreeDOS more near f_nodes is worth a try. They are sort of "short term working memory" for FreeDOS. Eric PS: Try loading the doslfn driver before you load lfnsort ;-) You may also want to use a FAT32 enabled kernel or set VERSION=7.10 ... |