LIGHTNING UK! Posted September 2, 2007 Posted September 2, 2007 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).
volvofl10 Posted September 2, 2007 Posted September 2, 2007 OR .................your machines working its little nutz off, and needs time to get its breath back before it can do anymore work
Shamus_McFartfinger Posted September 2, 2007 Posted September 2, 2007 OR............. your HD has slipped back into PIO mode making it work harder and slower than it should and making it unable to send data fast enough to your burner.
Cynthia Posted October 12, 2007 Posted October 12, 2007 (edited) Hi! Hijacking this old thread. Curious. Got one of these problems. Mostly due to installing another program at the same time as the burning went on. Not good... 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 October 12, 2007 by cynthia
dontasciime Posted October 12, 2007 Posted October 12, 2007 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.
Cynthia Posted October 12, 2007 Posted October 12, 2007 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 operationInstalled 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.
LIGHTNING UK! Posted October 12, 2007 Posted October 12, 2007 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'.
chewy Posted October 13, 2007 Posted October 13, 2007 a 12 minute gap for such a little update? It usually takes a video conversion hitting the same drive with a 4 gig write/author that I am using for source of the burn. Once was enough with that mistake for me
Cynthia Posted October 13, 2007 Posted October 13, 2007 (edited) 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 October 13, 2007 by cynthia
Cynthia Posted October 13, 2007 Posted October 13, 2007 (edited) Deleted. Edited October 13, 2007 by cynthia
LIGHTNING UK! Posted October 13, 2007 Posted October 13, 2007 cynthia, This is perfmon. 'Average Disk Queue Length' is one of the standard performance counters. The range 0 - 5 is just my own one, it's doesn't mean anything outside of Imgburn (you could use any range).
Cynthia Posted October 13, 2007 Posted October 13, 2007 Aha. It was that one. 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!
LIGHTNING UK! Posted October 13, 2007 Posted October 13, 2007 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
Cynthia Posted October 13, 2007 Posted October 13, 2007 Can my "high" average value be because of the disk was in "sleep" mode and the time to get it up and running again - creates a "to high" average value?
LIGHTNING UK! Posted October 13, 2007 Posted October 13, 2007 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
Cynthia Posted October 13, 2007 Posted October 13, 2007 (edited) Sorry, it was processortime I was looking at... 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. Some disk activity. Senast = Latest Medel = Average Lägsta = Lowest Högsta = Highest Varaktighet = Duration Edited October 13, 2007 by cynthia
LIGHTNING UK! Posted October 13, 2007 Posted October 13, 2007 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.
chewy Posted October 13, 2007 Posted October 13, 2007 would having several drives complicate the matter? P2P software? could windows kick in it's idle disk optimization and prolong the delay?
LIGHTNING UK! Posted October 13, 2007 Posted October 13, 2007 As mentioned in post 8, yes it's an average over ALL the drives, not just the 'source' drive. So any activity on any of the drives would push up the average and mean ImgBurn keeps waiting.
Cynthia Posted October 13, 2007 Posted October 13, 2007 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.
LIGHTNING UK! Posted October 13, 2007 Posted October 13, 2007 Yeah that's cool, I figured that was the case. 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
Cynthia Posted October 13, 2007 Posted October 13, 2007 (edited) 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... 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 October 13, 2007 by cynthia
LIGHTNING UK! Posted October 13, 2007 Posted October 13, 2007 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!
chewy Posted October 14, 2007 Posted October 14, 2007 so this phenomena is not related to burn speed? the long recovery glitch?
Recommended Posts