Peter, I have a small SD card driver here that I can compile either with the "standard" QDOS slaving mechanism or, alternatively, no slaving (except buffering the directory and one additional "scratch" block buffer) at all. Benchmarking even small, repeated accesses to files is 99% identical between both versions. SD card access is so fast that even on a standard QL finding a proper slave block is eating up the time that is needed to access the card directly.
I guess Adrian has only built this unusual "home-made" slaving mechanism into the QLSD driver because it was a leftover from SerUSB (where I can imagine that some sort of slaving is /very/ appropriate). Tobias > Am 15.03.2016 um 13:08 schrieb pg...@q40.de: > > A little remark on "conventional" buffering for QL mass storage > drivers. > > The situation for modern hardware is completely different than for > floppy and microdrive. For example, reading a block directly from > SDHC card on the QL is NOT slower than reading it from RAM! Modern > SDHC cards are so fast, that read accesses can happen back-to-back. > (And access to the QL ROM area, used by QL-SD, is even faster than > to the QL internal RAM area.) > > QL-style SLAVE block buffering would in most cases not speed up, but > slow down access to an SDHC card! Especially if the number of SLAVE > blocks is allowed to grow until all free RAM is used - which is the > convention. This effect had already been seen on the Q40/Q60 IDE > harddisk driver, where SLAVEing slowed down reading large files > extremely. Without a quick & dirty workaround that reduces buffer > space, the IDE driver would have become almost unusable. > > Ideally, a new compromise between buffer management overhead and the > benefit of abstracting very short scattered accesses from the > hardware block access level would be nice. > > Peter > > _______________________________________________ > QL-Users Mailing List _______________________________________________ QL-Users Mailing List
