Cache explorer, a small command line app by spath, was anounced over at CD Freaks today. It can test various aspects of drive caching including cache size, cache line numbers, FUA bit support, Plextor's special FUA command, and read cache disabling. This tool is mainly for experienced users, more information can be found in this thread.
Download:
http://download.cdfreaks.com/download/155 (http://download.cdfreaks.com/download/155)
CDFreaks discussion thread:
http://club.cdfreaks.com/showthread.php?t=184487 (http://club.cdfreaks.com/showthread.php?t=184487)
Seems that the program has problems with my Plextor PX-712A and querying my BenQ DW1655 freezes the whole system.
BTW, the correct thread address is http://club.cdfreaks.com/showthread.php?t=184487 (http://club.cdfreaks.com/showthread.php?t=184487)
I tested it on both of my drives, it worked find on my LG4167, but I had the same problem with a BenQ 1640 that other's have experienced. It didn't completely freeze my computer though.
C:\Tools>cachex -i -c -n 3 f:
CacheExplorer 0.7 -
Drive on F is HL-DT-STDVDRAM GSA-4167BDL10
- Buffer size: 2048 kB, read cache is enabled
- Supported read commands: BEh
- Testing cache line size:
36 kB / 16 sectors
36 kB / 16 sectors
36 kB / 16 sectors
C:\Tools>cachex -i -c -n 3 G:
CacheExplorer 0.7 -
Drive on G is BENQ DVD DD DW1640 BSJB
- Buffer size: 2048 kB
- Supported read commands: BEh
- Testing cache line size:
test aborted.
Hopefully this test becomes a standard procedure used to provide information for databases like the DAE Features webpage (http://www.daefeatures.co.uk/). It seems that EAC's cache detection is very buggy.
I am one person who got burnt thinking that the LG4167 drive doesn't cache audio data, because that is what EAC reports. But this utility confirms the information from Feurio that the LG4167 does infact cache 36 kB of data.
The program correctly works on three of the four drives I tested it on. Two of which properly take the fua command (one is a Plextor, one is a rebadged drive made by Plextor).
It cannot get any information for my Sony CDU5221. Perhaps a bad read command? EAC uses "MMC 1" for this drive.
About the LG41XX, since EAC requests more data than the size of the cache per read, doesn't the cache essentially get cleared with each read, or is this still a problem with re-reads if the amount of data being re-read is smaller?
About the LG41XX, since EAC requests more data than the size of the cache per read, doesn't the cache essentially get cleared with each read, or is this still a problem with re-reads if the amount of data being re-read is smaller?
just try it with a defective disc and cache flushing deactivated ... if no read errors (but sync errors) are reported, it is highly probable that the drive does indeed use its buffer for DAE.
IIRC, EAC operates with data chunks getting smaller during re-reading ... so even a small cache might influence DAE results ...
Does this tool need admin rights?
Does this tool need admin rights?
I believe so, yes.
About the LG41XX, since EAC requests more data than the size of the cache per read, doesn't the cache essentially get cleared with each read, or is this still a problem with re-reads if the amount of data being re-read is smaller?
Hi greynol
The smallest block size which is read is 64 kB, so usually every cache smaller than this block size does not count (as usually blocks larger than this value are read in one go)
But of course, to be really sure, it can be enabled though...
Source : http://www.digital-inn.de/106824-post3.html (http://www.digital-inn.de/106824-post3.html)
I'm investigating the bugs and I will also try to make the messages
more understandable (no drive caches 1 sector). As for admin rights,
it is mentioned in the text file
As for admin rights, it is mentioned in the text file
You mean RTFM? I did, when I downloaded it
Great tool BTW, hopefully you'll enhance it to an extent that it can be called MEAC (More Exact Audio Copy)
How do you make out its output? I forgot to bring the result with me now, however concerning FUA, it says that my LiteOn supports FUA, then it says its support is 3/5 or something like that.
Edit: You know... Stupid Typo
AFAIK, many drives support FUA, but EAC only supports the "-usefua" switch with Plextor drives [?]
Off topic question: I have LG 4165B DVD burner, does it cache the audio data when extracting audio CD?
It seems that EAC's cache detection is very buggy.
I am one person who got burnt thinking that the LG4167 drive doesn't cache audio data, because that is what EAC reports. But this utility confirms the information from Feurio that the LG4167 does infact cache 36 kB of data.
About the LG41XX, since EAC requests more data than the size of the cache per read, doesn't the cache essentially get cleared with each read, or is this still a problem with re-reads if the amount of data being re-read is smaller?
Off topic question: I have LG 4165B DVD burner, does it cache the audio data when extracting audio CD?
Do you know how much your LG 4165B caches?
Was spath's tool able to give you an answer?
Here's something that Martin H. showed me in another thread:
The smallest block size which is read is 64 kB, so usually every cache smaller than this block size does not count (as usually blocks larger than this value are read in one go)
But of course, to be really sure, it can be enabled though...
Source : http://www.digital-inn.de/106824-post3.html (http://www.digital-inn.de/106824-post3.html)
How do you make out its output? I forgot to bring the result with me now, however
concerning FUA, it says that my LiteOn supports FUA, then it says its support is 3/5
or something like that.
Two different FUA implementations are tested. First the standard use of FUA bit is
tested with ´-i´, but it is supported by very few drives ; if your drive does, you will
see something like ´D8h (FUA)´. Then the special Plextor FUA command is tested
with ´-p´, and more drives support it. Post your results with ´-d -n 10´switches
and I´ll tell you if it works for yours.
new version is up :
0.8 - fixed problems of '-i' with some BENQ firmwares (thanks to Mariusz)
- fixed bug with '-p -r' (thanks to Sebastian)
- fixed "1 sector cache" false results (thanks to Mariusz)
- added '-m' option
No problems with my Plextor PX-712A. Seems that the unit caches 1171 kB or 510 sectors. Moreover, Plextor FUA command is supported and worked 5/5 times, cache disabling does not work.
spath, I just tested my NEC unit again which used to report that one sector is cached and after about ten minutes using -c -r 0xbe, your tool reported "no cache detected" ten times. So, I take this means that my NEC really doesn't cache, right? Therefore, I can also tell EAC that the NEC doesn't cache.
What exactly does "read cache is enabled" next to the buffer size denote?
Will test with BenQ ASAP.
Edit: BTW, do you prefer replies here on HA, on CDFreaks or doesn't it matter to you?
I get some weird results with the BenQ:
First run with -c -r 0xbe
CacheExplorer 0.8 - spath@cdfreaks.com
Drive on G is BENQ DVD LS DW1655 BCHB
[+] Testing cache line size:
16 kB / 7 sectors
18 kB / 8 sectors
13 kB / 6 sectors
18 kB / 8 sectors
18 kB / 8 sectors
4 kB / 2 sectors
9 kB / 4 sectors
20 kB / 9 sectors
6 kB / 3 sectors
6 kB / 3 sectors
Second run:
CacheExplorer 0.8 - spath@cdfreaks.com
Drive on G is BENQ DVD LS DW1655 BCHB
[+] Testing cache line size:
13 kB / 6 sectors
13 kB / 6 sectors
13 kB / 6 sectors
13 kB / 6 sectors
13 kB / 6 sectors
4 kB / 2 sectors
13 kB / 6 sectors
13 kB / 6 sectors
13 kB / 6 sectors
13 kB / 6 sectors
During the first scan, the drive increased the speed since I could hear the CD speed up. During the second scan, the drive must have had a lower speed because I didn't hear anything, except for the spot where "4 kB / 2 sectors" was reported.
Edit: Third run:
CacheExplorer 0.8 - spath@cdfreaks.com
Drive on G is BENQ DVD LS DW1655 BCHB
[+] Testing cache line size:
55 kB / 24 sectors
13 kB / 6 sectors
13 kB / 6 sectors
18 kB / 8 sectors
121 kB / 53 sectors
11 kB / 5 sectors
4 kB / 2 sectors
4 kB / 2 sectors
4 kB / 2 sectors
20 kB / 9 sectors
So, I take this means that my NEC really doesn't cache, right?
Therefore, I can also tell EAC that the NEC doesn't cache.
yes
What exactly does "read cache is enabled" next to the buffer size denote?
It means exactly this, that the drive reports that its read cache is disabled.
It is in theory possible to completely disable the read cache (-k command),
but so far i've not seen a drive which supported it.
Regarding the BENQ results, the spinning speed has a direct influence on the
cache measurements, that's why '-l' and '-s' options are made for To make
a precise measure your drive should be spinning at max speed, e.g -l 15 -s 0.
Please let's continue at cdfreaks, no need to bother people here.
>Plextor FUA command
Why is it only a Plextor FUA command? the FUA bit is part to the standard MMC spec, has anyone tried it on a non-plextor drive which caches?
>Plextor FUA command
Why is it only a Plextor FUA command? the FUA bit is part to the standard MMC spec, has anyone tried it on a non-plextor drive which caches?
Because some plextor drives use a special command to flush the cache,
which is not the normal use of the FUA bit. I first mentioned this command
3 years ago on this board, and Wiethoff implemented it in EAC as '-usefua'.
Pardon my ignorance, but what exactly does this tool do? What is it useful for?
I have a Plextor 716A, would I need it?
It tells you if the drive caches and if yes, how large the cache is.
Off topic question: I have LG 4165B DVD burner, does it cache the audio data when extracting audio CD?
Do you know how much your LG 4165B caches?
Was spath's tool able to give you an answer?
Here's something that Martin H. showed me in another thread:
The smallest block size which is read is 64 kB, so usually every cache smaller than this block size does not count (as usually blocks larger than this value are read in one go)
But of course, to be really sure, it can be enabled though...
Source : http://www.digital-inn.de/106824-post3.html (http://www.digital-inn.de/106824-post3.html)
This last comment just confuses me further "usually every cace smaller than this block doe not count", but then the cache can be disabled. It seems to me that they are not quite sure if it has any effect or not. Maybe it matters, maybe it doesn't...
I think he is saying that it is ok to play it safe by checking the box even if it isn't necessary.
Just trying with a Plextor PA-230A - I have a hunch this drive does not cache (on re-reads of bad sectors it does not always take the same minimum number, so bad data is coming from somewhere on a re-read).
cacheex reports values all over the place (300KB to 1MB), my own routine also does the same....it is a tough Hombre.
@spath the machine it is tested on is a dual core machine - just want to check your timing routine is aligned to a specific processor (ie if using queryperformancecounter it will return different values from the different cpus). Don't really want to pull the drive to a single cpu system if not needed.
Just trying with a Plextor PA-230A - I have a hunch this drive does not cache (on re-reads of bad sectors it does not always take the same minimum number, so bad data is coming from somewhere on a re-read).
cacheex reports values all over the place (300KB to 1MB), my own routine also does the same....it is a tough Hombre.
Interesting, what is your method ?
@spath the machine it is tested on is a dual core machine - just want to check your timing routine is aligned to a specific processor (ie if using queryperformancecounter it will return different values from the different cpus). Don't really want to pull the drive to a single cpu system if not needed.
Nope, it's not "bad MP system proof". As Microsoft says, on a correct MP system we
should not have to care about procesor affinity when using QueryPerformanceCounter,
but I'll fix it anyway and release a new version this weekend. Thanks for the tip.
>release a new version this weekend. Thanks for the tip.
I doubt it is that, but want to be sure, I think it is down to this plextor type.
>Interesting, what is your method ?
You tell me yours and I will tell you mine?
Loop frame 0 to frame 1000, Rip LBA 0, rip LBA n (0 to 1000) and time. Store all times and look for a jump in time (against a running average).
I might rethink the routine to see if I can get it better, pehaps time the LBA 0 rip instead. What is yours?
Loop frame 0 to frame 1000, Rip LBA 0, rip LBA n (0 to 1000) and time. Store all times and look for a jump in time (against a running average).
I might rethink the routine to see if I can get it better, pehaps time the LBA 0 rip instead. What is yours?
It's the same, except that I trigger only when a new LBA0 rip time exceeds the previous
LBA0 rip time multiplied by a factor (-m sets the loop max value and -x sets the factor).
If you trigger on all time jumps this can explain the 1 sector difference, but the algorithms
are so close that we should always get the same values (+/-1). In any case, I'm convinced
that reading back LBA0 is really better than the old "forward only" method, which on some
very fast drives gave me the illusion of an infinite cache.
Further news on this...I changed the drive (plextor px-230a) to a single processor machine, cachex tends to detect 588 frames (most of the time), my program also detects this but I am not beleving it (as mentioned before I have seen this drive return different results during 2 sector re-reads).
So I have tried to come up with a simple test to determine a Yes / No does it cache before moving onto the detection routine. This is what I have at the moment:
A) it reads 5000 frames - 2 frames at a time and times.
B) reads 5000 frames - 2 frames, then re-reads those 2 fames before moving onto next 2 frames and times.
Now if the drive cached (ie took the 2nd 2 frame reread from the cache) then the (b) read pass should be longer than (a) pass but not a huge amount (as the second read comes from cache). The times for the plextor are:
a) 6 seconds
b) 13 seconds
This says to me this plextor does not cache. Thoughts? I have another drive that cleary does not cache:
a) 33 seconds
b) 400 seconds
You could add some additional logic (e.g. C = read double-frames four (4) times) assuming we're not approaching the minimum known cache size with a double frame. Then test the relavent time difference between A and B vs. B and C.
If B is right between A and C then it is caching, but if B is closer to C then it is not caching? The definition of "closer" might need to be experimentally obtained? Hmm, that first part doesn't sound right. Hmm. Nope, it's more complicated than that as there appear to be some resyncing issues with the second drive example that might be optimized around in newer drives regardless of cache enabled status.
Perhaps throwing out the A-type results and working only with the distances between B/C/D tests (2/4/6 rereads) might be useful? Or perhaps the time difference of those three, but with A subtracted from all of them?
Perhaps comparing against interleaved reads X,X-1,X+1 then (X+2),(X+2)-1,(X+2)+1, ..., etc., might give some numbers that would be useful?
It might be useful to get an idea of the possible cache algorithms and/or resync algorithms at work...
-brendan
My test is a simple:
if B > (A * 2) then it does not cache (the extra time will come from having to move the head back)
A) it reads 5000 frames - 2 frames at a time and times.
B) reads 5000 frames - 2 frames, then re-reads those 2 fames before moving onto next 2 frames and times.
Now if the drive cached (ie took the 2nd 2 frame reread from the cache) then the (b) read pass should be longer than (a) pass but not a huge amount (as the second read comes from cache). The times for the plextor are:
a) 6 seconds
b) 13 seconds
This says to me this plextor does not cache. Thoughts? I have another drive that cleary does not cache:
a) 33 seconds
b) 400 seconds
To me it says that the Plextor caches.
For a straight cache reloading strategy, the time difference between B) and A) is a linear
function of the total size read (it's independent of the cache size). Also the bigger the cache,
the closer B_time will be of 2*A_time, so for 588 sectors it makes sense (the ratio between
B and A is much bigger for your second drive). Also 588 sectors is a common result for Plextor
drives, so it confirms my opinion.
I'll fix it anyway and release a new version this weekend.
Not done yet because of insane work pressure, but it's still on the list.
Trying the test on a PX708a (without FUA disable) it takes 5 seconds to do test a, and 5 seconds to do test b as you would expect if it was just reading from ram, the 708 has a similar cache size.
With cache it should't take more than 2x the orignal time, otherwise it is slower than a drive without cache, so what would be the point of cache.
>588 sectors is a common result for Plextor
The drive might be doing something else other than loading a cache every 588, not sure what though.
This drive (230a) is quite a new plextor drive, you would think if it cached it would work with FUA which it does not, Plextools pro would not be able to clear the cache of this drive.
...also I have seen a 230a on a loop when re-reading the same sector give different values on the re-reads, in that instance the result did not come from the cache.
Can you think of a test that can be certain wether a drive caches or not?
D:\Stuff>cachex -i -c -n 3 q:
CacheExplorer 0.8 - spath@cdfreaks.com
Drive on Q is ATAPI COMBO52XMAX 1.20
[+] Buffer size: 2048 kB, read cache is enabled
[+] Supported read commands: BEh
[+] Testing cache line size:
no cache detected
no cache detected
no cache detected
This matches what Feurio reports where as
Drive on P is ASUS CRW-5224A 1.70
[+] Buffer size: 2048 kB, read cache is enabled
[+] Supported read commands: BEh
[+] Testing cache line size:
no cache detected
no cache detected
no cache detected
I am pretty sure that Feurio reports that the Asus caches.
CacheExplorer 0.8 - spath@cdfreaks.com
Drive on D is HL-DT-ST DVDRAM GSA-4167B DL11
[+] Buffer size: 2048 kB, read cache is enabled
[+] Supported read commands: BEh
[+] Plextor flush command: accepted
[+] Plextor flush tests: 4/5
C:\Documents and Settings\All Users\Tiedostot\Lataus\cachex>
What does a result of 4/5 indicate?
for fun, I did this to test the program:
CacheExplorer 0.8 - spath@cdfreaks.com
Drive on D is SAMSUNG CD-ROM SH-152A C505
- Buffer size: 128 kB
- Supported read commands: BEh
- Testing cache line size:
no cache detected
no cache detected
no cache detected
- Testing cache line numbers:
1 1 1
- Testing cache disabling: not supported
CacheExplorer 0.8 - spath@cdfreaks.com
Drive on G is PLEXTOR CD-R PX-230A 1.02
- Buffer size: 2048 kB, read cache is enabled
- Supported read commands:
- Plextor flush command: rejected
- Testing cache line size:
- Testing cache line numbers:
- Testing cache disabling: not supported
~D
This drive (230a) is quite a new plextor drive, you would think if it cached it would work with FUA which it does not, Plextools pro would not be able to clear the cache of this drive.
The PX-230A isn't made by Plextor, so why would you expect it to work with the FUA command?
Drive on G is PLEXTOR DVDR PX-760A 5a02
- Buffer size: 2048 kB, read cache is enabled
- Supported read commands: BEh D8h
- Plextor flush command: accepted
- Plextor flush tests: 3/3
- Testing cache line size:
581 kB / 253 sectors
581 kB / 253 sectors
581 kB / 253 sectors
- Testing cache line numbers:
1 1 1
- Testing cache disabling: not supported
decent, flush before reading a second time can avoid Cache DAE issues re: secure ripping, I haven't looked much into this drive model yet. I need more googlin' time, but I have not confirmed of DAE cache issue with this drive model. Don't fix it/flush it if it's not broken, yeah know?
~D
I forgot to say thank you Spath. I'm going to go hack around in cdparanoia a bit.
> so why would you expect it to work with the FUA command?
Plextor would have to be able to flush the cache if there was one in Plextools. I am guessing that Plextor also modify the firmware themselves.
> so why would you expect it to work with the FUA command?
Plextor would have to be able to flush the cache if there was one in Plextools. I am guessing that Plextor also modify the firmware themselves.
That sounds reasonable.
> Trying the test on a PX708a (without FUA disable) it
> takes 5 seconds to do test a, and 5 seconds to do
> test b as you would expect if it was just reading
> from ram, the 708 has a similar cache size.
I do not expect a) and b) to take the same time when
b) means reading two times the number of sectors of a),
even cached. For 5000/588 a drive would load the cache
8 times and read 2492 times from the cache. So reading
from the cache would have to be thousands of times
faster than reading from the disc to be neglectible in b),
and I've never seen any ratio higher than 200.
> With cache it should't take more than 2x the orignal
> time, ...
Well, it's true for just cache vs disk reading, but we are also
timing everything the firmware does like the ATAPI overhead,
what your OS does and so on. At 13 seconds you consider it
does not cache, under 12 seconds you would have said it
does : it's too close for me, especially compared to the factor
12 for your real non-caching drive.
> ... otherwise it is slower than a drive without cache,
> so what would be the point of cache.
No, a drive without cache would take much more time for
both a) and b) than a caching drive.
> The drive might be doing something else other than loading
> a cache every 588, not sure what though.
Maybe, but in a burst read how fast are sectors read after 588 ?
If all sectors 6xx are read much faster than sector 588, then
some caching must be involved.
> This drive (230a) is quite a new plextor drive, you would think if
> it cached it would work with FUA which it does not, Plextools pro
> would not be able to clear the cache of this drive.
You mean it doesn't work both with normal FUA and Plextools'
special FUA ? The simplest is to get latest Plextools and try
extracting a bad disc with this drive with Bustrace running,
then you'll see how it handles cache during re-reads.
> ...also I have seen a 230a on a loop when re-reading the same sector
> give different values on the re-reads, in that instance the result
> did not come from the cache.
Strange, i have no idea what is happening there.
> Can you think of a test that can be certain wether a drive caches or not?
Well, if it's just to determine about caching or not, timing the
difference between the initial read and following ones is very
robust. For instance, on a caching drive i get this :
cachex -i -. -c -m 10 -b 2 -n 1 e:
...
- Testing cache line size:
init 15000: 72.813915
15000: 0.652137
15001: 0.655490
15000: 0.579212
15003: 0.447052
15000: 0.666387
15005: 0.670020
...
73 ms to load the cache, then 0.6 ms to read 2 sectors from it.
Without cache, the ratio between initial and next reads is much
smaller. Can you try the same command on your 708 and 730 ?
Heres the results of the plextors:
Plextor PX-230A
C:\cachex.exe -i -c d:
CacheExplorer 0.8 - spath@cdfreaks.com
Drive on D is PLEXTOR CD-R PX-230A 1.01
[+] Buffer size: 2048 kB, read cache is enabled
[+] Supported read commands: BEh
[+] Testing cache line size:
1345 kB / 586 sectors
6 kB / 3 sectors
no cache detected
1345 kB / 586 sectors
1350 kB / 588 sectors
1350 kB / 588 sectors
780 kB / 340 sectors
1348 kB / 587 sectors
1350 kB / 588 sectors
1350 kB / 588 sectors
C:\>C:\cachex.exe -i -. -c -m 10 -b 2 -n 1 d:
CacheExplorer 0.8 - spath@cdfreaks.com
Drive on D is PLEXTOR CD-R PX-230A 1.01
[+] Buffer size: 2048 kB, read cache is enabled
[+] Supported read commands: BEh
command A8h rejected
command 28h rejected
command D4h rejected
command D5h rejected
command D8h rejected
[+] Testing cache line size:
init 15000: 95.516059
15000: 0.946626
15001: 0.971098
15000: 0.972642
15003: 0.966764
15000: 0.975249
15005: 1.278869
15000: 0.986146
15007: 1.590191
15000: 0.971432
15009: 1.466104
15000: 0.974060
no cache detected
------dBpowerAMP R12------
5312ms without re-read and 5750ms with re-read
587 sectors
--------------------
Plextor PX708a
C:\>cachex.exe -i -c e:
CacheExplorer 0.8 - spath@cdfreaks.com
Drive on E is PLEXTOR DVDR PX-708A 1.12
[+] Buffer size: 2048 kB, read cache is enabled
[+] Supported read commands: BEh D8h
[+] Testing cache line size:
581 kB / 253 sectors
581 kB / 253 sectors
581 kB / 253 sectors
581 kB / 253 sectors
581 kB / 253 sectors
581 kB / 253 sectors
13 kB / 6 sectors
581 kB / 253 sectors
581 kB / 253 sectors
581 kB / 253 sectors
C:\>cachex.exe -i -. -c -m 10 -b 2 -n 1 e:
CacheExplorer 0.8 - spath@cdfreaks.com
Drive on E is PLEXTOR DVDR PX-708A 1.12
[+] Buffer size: 2048 kB, read cache is enabled
[+] Supported read commands: BEh
command A8h rejected
command 28h rejected
command D4h rejected
command D5h rejected D8h
command D8h with FUA bit rejected
[+] Testing cache line size:
init 15000: 67.844187
15000: 0.617817
15001: 0.525929
15000: 0.548503
15003: 0.640503
15000: 0.609329
15005: 0.539712
15000: 0.549165
15007: 0.629210
15000: 0.547930
15009: 0.556209
15000: 0.599586
no cache detected
------dBpowerAMP R12------
3844ms without re-read and 3844 with re-read
254 sectors
-------------------------
Retesting the PX230A on a different CD:
Drive on E is PLEXTOR CD-R PX-230A 1.01
[+] Buffer size: 2048 kB, read cache is enabled
[+] Supported read commands: BEh
command A8h rejected
command 28h rejected
command D4h rejected
command D5h rejected
command D8h rejected
[+] Testing cache line size:
init 15000: 92.982701
15000: 1.052926
15001: 0.958790
15000: 0.967066
15003: 1.589474
15000: 0.971994
15005: 2.216799
15000: 0.972971
15007: 2.172395
15000: 1.003475
15009: 0.994602
15000: 0.953897
no cache detected
C:\>cachex.exe -i -c e:
CacheExplorer 0.8 - spath@cdfreaks.com
Drive on E is PLEXTOR CD-R PX-230A 1.01
[+] Buffer size: 2048 kB, read cache is enabled
[+] Supported read commands: BEh
[+] Testing cache line size:
656 kB / 286 sectors
142 kB / 62 sectors
165 kB / 72 sectors
6 kB / 3 sectors
32 kB / 14 sectors
no cache detected
408 kB / 178 sectors
847 kB / 369 sectors
1274 kB / 555 sectors
803 kB / 350 sectors
I am beginning to think the 230A does cache. FUA clear does not work.
I am beginning to think the 230A does cache. FUA clear does not work.
It surely does ... it's a BenQ OEM drive ...
init 15000: 95.516059
15000: 0.946626
init 15000: 92.982701
15000: 1.052926
With these figures it seems clear to me that PX-230 does indeed cache.
I am wondering about one thing... If I test the Plextor FUA command and use 10 tests, the result is 5/10. I also tried with higher test numbers and it seems that my PX-755A doesn't use the cache only 5 times, the result being 5/x for x values being ≥ 5.
Also, I performed this test with my LG E10L and it seems that it also supports the Plextor FUA command - or at least that is what I understand. The results are always 3/3, 5/5, 10/10, 20/20...
My results for a PX-755SA:
D:\Temp\cachex>cachex.exe -i -c e:
CacheExplorer 0.8 - spath@cdfreaks.com
Drive on E is PLEXTOR DVDR PX-755A 1.02
[+] Buffer size: 2048 kB, read cache is enabled
[+] Supported read commands: BEh A8h(FUA) 28h(FUA) D4h(FUA) D5h(FUA) D8h(FUA)
[+] Testing cache line size:
581 kB / 253 sectors
581 kB / 253 sectors
581 kB / 253 sectors
581 kB / 253 sectors
581 kB / 253 sectors
581 kB / 253 sectors
581 kB / 253 sectors
581 kB / 253 sectors
581 kB / 253 sectors
581 kB / 253 sectors
D:\Temp\cachex>cachex.exe -i -. -c -m 10 -b 2 -n 1 e:
CacheExplorer 0.8 - spath@cdfreaks.com
Drive on E is PLEXTOR DVDR PX-755A 1.02
[+] Buffer size: 2048 kB, read cache is enabled
[+] Supported read commands: BEh A8h(FUA) 28h(FUA) D4h(FUA) D5h(FUA) D8h(FUA)
[+] Testing cache line size:
init 15000: 73.634535
15000: 0.636211
15001: 0.582565
15000: 0.562727
15003: 0.664152
15000: 0.610506
15005: 0.647388
15000: 0.539257
15007: 0.920648
15000: 0.618609
15009: 0.888516
15000: 0.635652
no cache detected
As you can see, it doesn't report the fact that my drive is SATA, giving the wrong model number.
As for EAC, with the -usefua switch the red blocks fill up at normal speed when it encounters errors, without it, it fills up really fast. I would suppose this is because the sectors are read from cache, and so that the -usefua switch works for me. I haven't been able to detect differences yet but i haven't tested a lot yet either.
In case anybody's looking for this tool, I was lucky enough to grab the source when spath made it available in the (now long gone) CDFreaks forums.
You can find it here : https://github.com/xavery/cachex