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

CDFreaks discussion thread:
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

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.


Hopefully this test becomes a standard procedure used to provide information for databases like the DAE Features webpage. 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?

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?

I believe so, yes.

Hi greynol


Source : 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

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?

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:

Source : http://www.digital-inn.de/106824-post3.html

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



Second run:



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:

yes


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?

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.

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.

Interesting, what is your method ?

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?

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)

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.


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?

This matches what Feurio reports where as

I am pretty sure that Feurio reports that the Asus caches.

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

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.

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


Plextor PX708a


Retesting the PX230A on a different CD:


I am beginning to think the 230A does cache. FUA clear does not work.

It surely does ... it's a BenQ OEM drive ...

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:


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.