You got it... I replace the ATIRadeon.chip file in kickstart with the one in OS4 Pre4 and the speed loading is like before.
Now... you know how it is sometimes, we fix some bug(s) and create new one(s)! ;o) I Hope it is a bug!
Yes, but in Collector.
Quote:
Now should I keep the old ATIRadeon.chip?
Of course not, you have this bug back (no working WaitTOF()), no overlay support, etc. with the Update4 version. Install the AmigaOS4 final version again. To fix the problem in Collector load the Colloctor020 executable (111452 bytes, md5sum d4d281063da710d103a90fc0adf04f3a) into a hex editor and at offset 0x1ABD8 (109528) change 2 bytes from 2F 0E to 4E 75. If you have the 68000 executable installed (111944 bytes, md5sum 8b4e3e9ec8a6e8a5ed3a3c5bf5fcfc7b) the offset is 0x1ADC4 (110020).
I'm having a hard time believing a 12MB index file could load in under 2 sec.
Why? If it's not in the disk caches yet loading 12 MB takes about 0.2-0.4 seconds, if it's cached already it takes less than 0.1 seconds. But Collector loads it with over 10000 tiny reads instead of a few small ones which slows it down a lot, it probably does some other things while loading the data, and it's an emulated m68k executable, which results in a load time of about 2-3 seconds for this index file here after removing the useless screen refresh sync waiting from the Collector executable. Even loading it from a FFS2 partition takes only about 5 seconds with the patched Collector executable.
A bug in Collector? I could not beleive that! eheh
The patche you wrote work very well... what it does exactly?
Collector uses the graphics.library function WaitTOF() ("Wait for the top of the next video frame"), probably to sychronise the display of the progress gauge with the screen refresh rate, which doesn't make any sense and only slows it down (unless you have an incomplete graphics driver like the Update4 ATIRadeon.card which does nothing when WaitTOF() is called). For example games can use the WaitTOF() function after rendering a frame and wait until it's time for the next one, that way you get for example 80 FPS if you are using a 80 Hz screenmode since it makes no sense to render 200 FPS when the monitor only updates the display 80 times per second. My patch disables the WaitTOF() calls in Collector.
Why is it slow? The micro doesn't have the DMA problems an unfixed XE has and you can use UDMA. The default is PIO, you have to switch it manually to UDMA, by putting something like "C:idetool -x a1ide.device 0 69" in your S:User-Startup or by setting U-Boot variables. A SII0680 could only be faster if you would have a HD which is faster than 100 MB/s since the max. speed on the VIA is UDMA5 (100 MB/s) while the SII0680 supports UDMA6 (133 MB/s).
Quote:
I applied your change, but still slow here. Are you guys using a sil card?
I'm using a SII0680, but I just switched it to PIO4 and it's still much faster than without the patch. Without the patch the index file posted here takes 23 seconds to load, no matter if I use UDMA or PIO, with the patch it takes 2-3 seconds with UDMA5 and 4-5 seconds with PIO4 loading it from a SFS partition. I have an old HD connected to the VIA as well, which of course runs in PIO mode since my XE isn't fixed, and even loading it from a FFS2 partition from the HD connected to the VIA it takes only about 5 seconds with the patch and 23 seconds without the patch.
In reference to Collector loading the index, it went from 28 secs to under 2 sec to load after the patch, pretty impressive as I would never have believed it.
USB CF cards are slow, especially some older cards. I did some speed tests with my card & this is what I got copying that 12MB file.
HD > CF 48 secs CF > HD 15 secs HD > HD 15 secs
Partition to partition is under 2 secs & the HD to HD seems way to slow to me, but I have no idea what I'm missing. Both drives are set to UDMA 5 & use SFS. Could be because each HD is on a separate ide port.
If your system has no problems using DMA, you should be using it.
Look, only one leg, count em, one! X1000/PA6T@1800MHz/2Gb/Radeon 4850
USB CF cards are slow, especially some older cards. I did some speed tests with my card & this is what I got copying that 12MB file.
HD > CF 48 secs CF > HD 15 secs HD > HD 15 secs
Partition to partition is under 2 secs & the HD to HD seems way to slow to me, but I have no idea what I'm missing. Both drives are set to UDMA 5 & use SFS. Could be because each HD is on a separate ide port.
No, that should be faster than 2 partitions on the same HD. What did you use for copying?
If you use the workbench add/change the BUFSIZE tooltype in AsyncWB to BUFSIZE=10485760 (if you want to use something else make sure it's a multiple of 65536, for example using BUFSIZE=1000000 would cause slow partial block reads/writes), the default buffer size is very small causing very slow copies. (BUFSIZE is in bytes.)
If you use C:Copy in a shell use something like "copy buffer 20000 source dest", the default is a small buffer (= slow copy) as well. (BUFFER is number of blocks.)
If you use something else for copying check the configuration/options and if there is a setting/option to change the buffer size increase it to a few MB.
The speedup loading patch was for Collector 3.5, a thumb creation app for images. If you're running Collector, the patch is in post #22. Post #32 has the hints for speeding up a DOS copy function.
Look, only one leg, count em, one! X1000/PA6T@1800MHz/2Gb/Radeon 4850
I use DOpus v4.18 ppc for copying. I uncommented the BUFSIZE tooltype in AsyncWB & put in your buffer size & that made a big difference, a 12MB file copies in under 1 sec now. I have some avi movie files that are 700MB in size & they copy in 55 sec. Does that sound normal? Buffers=1000 & blocksize=1024. I played with bigger block sizes, but no difference in copy time.
Look, only one leg, count em, one! X1000/PA6T@1800MHz/2Gb/Radeon 4850
I just checked and didn't find an option to change the copy buffer size in it's configuration, plese tell the current maintainer of the AmigaOS4 version of DOpus4 to increase the size of the buffer it's using for copying to at least 5 or better 10 MB, or make it configurable.
Quote:
I uncommented the BUFSIZE tooltype in AsyncWB & put in your buffer size & that made a big difference, a 12MB file copies in under 1 sec now. I have some avi movie files that are 700MB in size & they copy in 55 sec. Does that sound normal?
That's about 25 MB/s (reading 700 MB + writing 700 MB / 55 seconds), if source and destination are on the same HD it's OK. If source and destination are on different HDs, especially if both are on different ports, it should be faster.
Quote:
Buffers=1000 & blocksize=1024. I played with bigger block sizes, but no difference in copy time.
I thought you are using SFS? SFS doesn't get faster with larger blocksizes, some operations even get slower with larger blocks. You should always use 512 bytes/block for SFS partitions (but you don't need to reformat your partitions if you used something else, the differences are minimal). On FFS2 partitions it should make a big difference, 512 bytes/block is very slow with FFS, you should use 2048 bytes/block for normal FFS2 partitions on which most file are small (Workbench, etc.), and 4096 or 8192 bytes/block for partitions used only for very large files like videos, CD images, etc.
joerg wrote: [...] If you use the workbench add/change the BUFSIZE tooltype in AsyncWB to BUFSIZE=10485760 (if you want to use something else make sure it's a multiple of 65536, for example using BUFSIZE=1000000 would cause slow partial block reads/writes), the default buffer size is very small causing very slow copies. (BUFSIZE is in bytes.)
stupid question but why isn't this set as default in the tooltypes? if this is better/faster in general?
Quote:
If you use C:Copy in a shell use something like "copy buffer 20000 source dest", the default is a small buffer (= slow copy) as well. (BUFFER is number of blocks.)
can i set this somewhere as default? it's not nice to add this every time when typing the copy command.
Quote: "I just checked and didn't find an option to change the copy buffer size in it's configuration, plese tell the current maintainer of the AmigaOS4 version of DOpus4 to increase the size of the buffer it's using for copying to at least 5 or better 10 MB, or make it configurable."
The copy/move command is internal & probably hasn't been touched. I'll have zerohero take a look at them as he's the maintainer & porter. I did a copy from shell with your buffer setting & got a copy time of 50 sec, a bit faster then with DOpus.
Quote: "I thought you are using SFS? SFS doesn't get faster with larger blocksizes, some operations even get slower with larger blocks."
I am using SFS on all my partitions, 2 HDs, 1 400GB with 15 partitions & 1 80GB, all one partition for backups. The bigger partitions I'm using 1024 blocksize, but I'll change them to 512 & re-format.
As far as copying a 700MB file, I get 50-55 secs from partition to partition & HD to HD, no difference in time.
Big thanks for your help & answers.
Look, only one leg, count em, one! X1000/PA6T@1800MHz/2Gb/Radeon 4850
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
