DOS ain't dead

It seems the fastest method(s) are as follows:

* copy while only reading in one pass, avoiding spurious reads (a la TurboCopy)
* XMS (a la MS-DOS 6.2+ XCOPY? or ZCOPY)
* 32-bit, aligned code, optimized appropriately (a la NDN)
* SMARTDRV etc. (a la LBACACHE)
* DMA, UDMA (a la UIDE)
* direct sector manipulation (TurboCopy ???)

Well, xWCopy is pretty fast too, and it doesn't really do it optimally at all, nor RxCopy, IIRC. So who knows, who cares, only for really big files does it even matter. Patience is a virtue.

EDIT: I think FD DISKCOMP (and/or DISKCOPY ??) uses MD5 to avoid re-reading too much.

> EDIT: Also here's some stuff Eric sent us per mail for whatever reason:

Here's some more, for completeness:

> On one hand, FreeDOS
> does not implement secondary caches in the kernel. On the other
> hand, you can use TICKLE together with LBACACHE for readahead...
>
> Make sure to read the docs or at least /? screens to use options
> properly, you have to enable e.g. lba harddisk readahead manually.
>
> I think the cache by Jack also had something with readahead? And
> of course it is quite possible that your disk has it built in so
> you only have to wait for the piece by piece transfer while the
> disk already buffered larger chunks in the RAM inside the drive.
>
> Of course it is faster to do a real readahead. You could even set
> the "cooling" temperature mode of LBACACHE, do a dir /s or do e.g.
> chkdsk or dosfsck, and then switch back to normal temperature, to
> force the FAT and DIR data into the cache before copying.
>
> Anyway... My theory is still that seeks and small writes to the
> FAT are what makes copying slower, so tweaking read speed or the
> speed of file content read / write may have only small effects.
>
> As usual, you can try whether a write pooling or delayed write
> cache helps you, for example the NWCACHE from DRDOS... You can
> probably find some suggested command line options for that in
> your mail archives and the freedos mailing list archives...

> Hi, a comment on the dos copy command threat: Try first setting
> the file to the right size (seek to end-1, write a byte, close)
> and then reopen the file and start writing data, for example in
> 32k blocks, taking care that the 32k buffer does not wrap around
> a multiple of 64k in terms of linear address / DMA boundary. The
> idea is that setting the final size immediately avoids having to
> update the FAT again later: The file size does not change later,
> while it would change all the time if starting with an empty file
> and appending data to it until all content is there...
>
> Eric

I did a brief test by setting the size of the default.$$$ to the same size as the default.zip prior to add a file to the archive. The file size will change later, but the copying prior to the adding takes a long time, and this increase for each file in the loop.

\doszip\src\clib\zip\wzipadd.asm:

    wzipadd_copylocal:
        xor     ax,ax
        mov     local_size_ax,ax
        mov     local_size_dx,ax
        inc     ax
        cmp     copy_fast,al
        jne     wzipadd_copyslow
  ifdef ERIKS_FASTCOPY
        mov     ax,4200h + SEEK_END     ; get .ZIP file size
        mov     bx,STDI.ios_file
        xor     cx,cx
        mov     dx,cx
        int     21h
        jc      wzipadd_error
        push    dx
        push    ax
        mov     ax,4200h + SEEK_SET     ; back to start..
        mov     bx,STDI.ios_file
        xor     cx,cx
        mov     dx,cx
        int     21h
        pop     dx
        pop     cx
        or      cx,cx
        jnz     wzipadd_size_ok
        cmp     dx,16
        jb      wzipadd_skip            ; skip if < 16 byte
    wzipadd_size_ok:
        sub     dx,1
        sbb     cx,0
        mov     ax,4200h + SEEK_SET     ; seek outfile to size-1
        mov     bx,STDO.ios_file
        int     21h
        jc      wzipadd_error
        mov     bx,STDO.ios_file
        mov     cx,1
        mov     ax,4000h                ; write one byte
        int     21h
        jc      wzipadd_error
        mov     ax,4200h + SEEK_SET     ; back to start..
        mov     bx,STDO.ios_file
        xor     cx,cx
        mov     dx,cx
        int     21h
    wzipadd_skip:
  endif


This reduced the compression time from 455 to 180 sec.

> I found a description of the buffers command in "QUE - Using MS-DOS 6.2".

Thanks, that explains it to me somewhat.

---
l