Jump to content

buffer recovery threshold


Pestam

Recommended Posts

When the main buffer is below the value of 'Main' and the device buffer is below the value of 'Device' (for a certain preset period of time), buffer recovery kicks in and waits for:

 

1. The buffer to refill.

2. The hdd activity (Average Disk Queue length) to reach the the value of 'Avg Disk Q'. (This is a performance counter that you can monitor in the same way you do CPU usage).

Link to comment
Share on other sites

  • 1 month later...

Hi! :)

 

Hijacking this old thread. :teehee:

 

Curious. Got one of these problems. Mostly due to installing another program at the same time as the burning went on. Not good... :whistling:

 

Even if it was another harddisk that was used for the programinstallation (C: ) as the burning went from H: (Internal PATA).

 

My first reaction was to kill the burning - but I let it run. But even if the installation of that other program was done - it took long time (approx 8 -9 minutes) before it started to recover and continue to burn.

 

Is there something that can be changed to get it up and burning faster again after this type of situation?

 

There are some settings in the I/O tab; Main/Device/Avg. Disk. Q. But what on earth those these stand for and will changing these have changed the situation?

 

:)

 

I 20:15:58 ImgBurn Version 2.3.2.0 started!

I 20:15:58 Microsoft Windows Vista Ultimate Edition (6.0, Build 6000)

I 20:15:58 Total Physical Memory: 2 095 616 KB - Available: 1 270 552 KB

I 20:15:58 Initialising SPTI...

I 20:15:58 Searching for SCSI / ATAPI devices...

I 20:15:58 Found 2 DVD±RWs!

I 20:16:00 Operation Started!

I 20:16:00 Source File: H:\DUCK.ISO

I 20:16:00 Source File Sectors: 2 131 141 (MODE1/2048)

I 20:16:00 Source File Size: 4 364 576 768 bytes

I 20:16:00 Source File Volume Identifier: DUCK

I 20:16:00 Source File Application Identifier: MKISOFS ISO 9660/HFS FILESYSTEM BUILDER & CDRECORD CD-R/DVD CREATOR

Edited by cynthia
Link to comment
Share on other sites

Long time no see Cynthia.

 

Check Hard drive Iso is stored on for errors(file system option not scan for bad sectors), Defrag the same hard drive afterwards.

 

What was program your were installing, did it have anything to do with storage/ or install any driver for ide controller or an I/O operation

 

Suppose you could raise buffer a bit.

 

If writer and ISO/C: share IDE maybe change that so are on seperate channels. Or stick In SATA hard drive as well.

Link to comment
Share on other sites

Long time no see Cynthia.
Nice to see you. :)

 

Check Hard drive Iso is stored on for errors(file system option not scan for bad sectors), Defrag the same hard drive afterwards.
Only thing on that PATA disk was that .ISO file.

 

What was program your were installing, did it have anything to do with storage/ or install any driver for ide controller or an I/O operation
Installed Java 6 update 3.

 

Suppose you could raise buffer a bit.
I'll raise it.

 

If writer and ISO/C: share IDE maybe change that so are on seperate channels. Or stick In SATA hard drive as well.
C: is a SATA and the H: is a PATA. The H: is also on another channel (RAID PATA - even if the harddisk is not set up as a true RAID (=mirroring)) than the burners. The burners are on the same PATA channel.
Link to comment
Share on other sites

This is probably more my problem than yours, I believe it takes the average queue length of *all* drives rather than just the *source* drive, so that's why it took ages to recover (the drive you were installing to was still busy and therefore pushing up the average). Of course that doesn't really explain why the buffer went down below the threshold level in the first place - but I believe that's just the way windows works. Doing a lot of I/O on one drive will slow down all of them.

 

Raising the buffer won't actually make it recover any quicker - if anything it'll take longer as there's more buffer to fill (but it could make the pause less likely to happen in the first place). To make it less sensitive to disk activity (and therefore start back up faster), you'd need to increase the 'Avg. Disk Q' value. The program won't start back up until the 'Average Disk Queue Length' drops below the value you set - you can monitor that value by running 'perfmon.msc'.

Link to comment
Share on other sites

Tried to search on the net to see what the range 0-5 stands for - but no luck. Also ran that program - but couldn't spot that value in any of those windows or reprorts.

 

Moved it up to 5.

 

@chewy: The update only took a few minutes - then ImgBurn waited another 10 minutes before it started again. During that time no installation in progress. Guess it's something about an average value that needs to get down - before it kicks of the burning again.

 

:)

Edited by cynthia
Link to comment
Share on other sites

Aha. It was that one. smileyShame.png

 

Looks as at idle it's 1.7 in average and the highest value is 18.9.

 

Guess it's safer not to install anything while burning. Even if that disc burned and verified ok.

 

Thanks for the help! :)

Link to comment
Share on other sites

If yours is at 1.7 when the machine it totally idle then I guess you need to change it from the default of 0.8 to something like 1.5 - otherwise every time the buffer recovery kicks in it's going to take forever to start burning again.

 

1.7 does seem a tad high though :/

Link to comment
Share on other sites

It could be anything where the disc is too busy/unable to process all the I/O requests.

 

That's the idea of the 'Disk Queue'. If there are lots of I/O requests being made and the drive is too slow to cope, the queue length obviously increases - until a point where I guess the OS just rejects them or something.

 

Is your drive a slow/old one? Is it partitioned / compressed or anything?

 

You can see the queue length I get in that screenshot... I have quite a beasty hdd setup and it's almost always on zero when I'm not doing anything and it's hard for me to judge what a 'normal' setup might idle on.

 

This might be useful: http://technet.microsoft.com/en-us/library/aa997558.aspx

Link to comment
Share on other sites

Sorry, it was processortime I was looking at... idiot2.gif

 

Noticed you need to manually add the strings for average que time in that M$ program. So now it looks more like your image.

 

The H: drive is a rather old (2-3 year) PATA 160 GB disk. Only one large partition and no compression.

 

I guess my basic problem is that the average q value takes some time (around 10 minutes - based on the burning log) to get down under the limit you can set in the preferences of ImgBurn.

 

Here is it when it's idle.

 

2003679654450906498_rs.jpg

 

Some disk activity.

 

2003684313730082144_rs.jpg

 

Senast = Latest

Medel = Average

Lägsta = Lowest

Högsta = Highest

Varaktighet = Duration

Edited by cynthia
Link to comment
Share on other sites

Those pics only show it going up to 0.731, which of course is still below the 0.8 default value in the settings - hence it wouldn't be waiting.
These shots are not from the time when the installation took place. I guess you need to put the M$ on monitoring to get old values.
Link to comment
Share on other sites

It's just you said it was on 1.7 when idle in an earlier post. It must not have been quite so idle then as it was in the 0.731 pic :)
Yes, that was me mixing up the bananas with apples... :teehee:

 

I gave you wrongly the "processor time %" value. It was that value that was 1.7. It's the default value that shows up in that graph in the M$ program. Sorry for that.

 

But would it not be more appropriate to use the drives q value that you use as source for the burning as trigger for the "hard disk activity to reach threshold level"?

Edited by cynthia
Link to comment
Share on other sites

Seems Microsoft changed the default performance counters visible between XP and Vista. I was going by what XP (or in my case Server 2003) shows but it appears you're on Vista - so really it's all my fault ;)

 

Yes it would be better to use the individual drives queue length.... but only sometimes! (I did kinda say that in my first post when I said it was my problem and not yours!)

 

Disk activity in general will slow the system and of course the same hdd could be partitioned several times. I cannot ignore those other partitions and it was just too much of a pain to attempt to get it perfect for the number of times this issue would actually crop up - you're the first I've heard of where it waits for an unreasonable amount of time.

 

Not only that, the burn code is the same for all modes and whilst it would be possible to get the source drive for an image burnt in Write mode, it's a whole lot harder when burning loads of folders/files in Build mode!

Link to comment
Share on other sites

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.