ben m
Joined: 15 Sep 2002
Posts: 337
Location: UK |
| Week 3 - Computers Practical |
 |
|
Hi,
this week you guys are going to have a go at some basic Audio PC benchmarking!
What I would like you to do is create a way of benchmarking your system - i.e. seeing how many tracks you can run simultaneously.
Obviously for this you'll need to have a 'standardised' file.
I'd recommend that you use a mono audio file of around 2-3 minutes in length.
You'll then want to duplicate this track in your sequencer until you find your PC can no longer handle it and starts to click/pop/drop out etc
You may want to monitor CPU and HD performance.
After you have noted this, we can try to increase performance;
Firstly you'll need Dskbench;
http://www.sesa.es/us/dskbench/dskbench.htm
Please note that for best results this needs to be ran in DOS, or at the least a control prompt window within windows. It also needs to be ran from the drive you would usually record audio to.
Instructions for use should be included within the .zip file.
Running this util will demonstrate the optimal disk buffer sizes for your system. After finding the best value, change the value in your sequencer to match and then run the 'audio track' test again and see if there is any improvement.
If you need any help then post a message in this thread.
Update your progress in this thread and we can chat about it in the workshop next week too! |
Mon Mar 22, 2004 7:19 pm |
|
|
hoggs33
Joined: 09 Feb 2004
Posts: 55
Location: Nottingham, England |
Hi Ben - had a quick go at seeing how many tracks I can play simulateously - not sure if I am doing it correctly though. I have taken a track by Air at around 2m45secs and converted it to a mono wav file which I have then imported into into my sequencer software (Sonar 3). I have copied it to new tracks and got up to 180 tracks playing at the same time without any noticeable clicks or pops with the CPU peaking around 86% although the meters etc were running a bit slow at this. At 186 tracks I was getting click and pops and a CPU warning - does this sound about right or am I doing something wrong? - Have downloaded the DskBench Util but no sure really what to do with it yet!!!! - will have to have a proper look tommorrow.
Duncan |
|
Wed Mar 24, 2004 4:06 am |
|
|
|
|
ben m
Joined: 15 Sep 2002
Posts: 337
Location: UK |
| Moon Safari |
|
|
Hey Duncan,
yes, you're on the right lines there. Good choice with Air as well! 
If you're getting in the region of 200 tracks as you are, you may find it beneficial to run a stereo track instead as this should half the number of tracks that you need to add.
186 is a good track count though - what are your system specs (most importantly CPU speed, and HD specs in GB and rpm as well as IDE channel)
Although we are primarily looking at HD performance, you may also want to try adding a plug-in such as a compressor to each channel as well and seeing how many tracks you lose to lack of CPU power.
As far as dskbench goes, the program ascertains the optimal disk buffer size for your system and it can make a drastic improvement to the number of tracks you are running. In Cubase for instance, you should have a number of disk buffer options calibrated in kb. I'm not a regular Sonar user but I am pretty sure that there are options for disk buffer settings in the control panel.
I won't go into detail as to the workings of the buffer right here as you have a question on buffers this week and I don't want to give too much away 
Let us know how you get on,
ben m |
|
Wed Mar 24, 2004 6:17 am |
|
|
hoggs33
Joined: 09 Feb 2004
Posts: 55
Location: Nottingham, England |
MY PC is fairly new so it's not clogged up yet with loads of crap downloaded from the internet!!!!
Its running Windows XP, has a Pentium 4 3.06GHz CPU with 512MB of RAM. It has got 3 internal hard drives one of which I keep just for music plus an external hard drive which I use basically for ripping CD's to for my iPod. In total there is 240GB of HD memory.
Sonar does have buffer settings that can be adjusted.
I will try the things you suggested and report back!!
Duncan |
|
Thu Mar 25, 2004 3:37 am |
|
|
|
|
griff505
Joined: 23 Feb 2004
Posts: 68
Location: Bristol |
where does it display the optimal disk buffer size?? |
|
Thu Mar 25, 2004 7:27 am |
|
|
ben m
Joined: 15 Sep 2002
Posts: 337
Location: UK |
|
|
|
Ok, below I've reproduced an article co-writte by the author of dskbench. It outlines the meaning of all the information that the app provides.
The original is here;
http://www.digitalprosound.com/Htm/TechStuff/June/SCSIvs-P5_1.htm
DAW Disk Benchmark
There may be a lot of disk performance benchmark tests out there, but the only one that seems to pin-point drive performance as it relates to the DAW is DSKBENCH written by this article's co-author, José Catena. It is available for downloading from the SESA Inc. web site at http://www.sesa.es by clicking on the DOWNLOADS link in the left hand frame. Unzip the package, read the docs and then move the EXE file to your WINDOWS directory or in some other directory that is in your DOS PATH. To use it, open a DOS window and at the prompt, log on to the drive you wish to test. At the next prompt, type DSKBENCH and the program will start to run. If you wish to make a record of the resulting analysis, add the ">" redirect command at the end and send the output to a text file of your choice, such as this:
DSKBENCH > C:\TEMP\RESULTS.TXT
You don't need to use upper case type. It is used here to make it easier to read. In the above example, the program will run without printing anything to your display, but will instead write everything to a text file called RESULTS.TXT that will be created in your C:\TEMP folder. You can send it to any folder you wish, of course.
Here is an example of what you will get by running this program:
DskBench 2.11
(c) 1998, SESA, J.M.Catena (admin@sesa.es, www.sesa.es)
Timer Check = 990 (should be near 1000)
CPU Check = 50.40 % (should be near 50.00 %)
CPU index (relative to Pro 200 MHz) = 0.900380
Open = 4 ms
Write = 43105 ms, 5.94 MB/s, CPU = 7.88 %
Flush = 283 ms
Rewin = 0 ms
Read = 39995 ms, 6.40 MB/s, CPU = 5.31 %
Close = 193 ms
BlockSize = 131072, MB/s = 4.45, Tracks = 52.94, CPU = 6.06 %
BlockSize = 65536, MB/s = 3.18, Tracks = 37.85, CPU = 3.74 %
BlockSize = 32768, MB/s = 2.00, Tracks = 23.73, CPU = 3.67 %
BlockSize = 16384, MB/s = 1.10, Tracks = 13.10, CPU = 3.47 %
BlockSize = 8192, MB/s = 0.58, Tracks = 6.87, CPU = 3.40 %
BlockSize = 4096, MB/s = 0.30, Tracks = 3.53, CPU = 3.51 %
The first part of the readout is just to make sure there isn't something drastically wrong with your CPU timing system. As long as the numbers are close, don't worry about them. The CPU index is a comparison of the relative processing power of your CPU to that of a reference standard - in this case, a Pentium Pro 200 MHz. The above readings were taken on a Pentium MMX 166 MHz and so reports in at only 90% of the Pro 200's power.
The disk performance numbers start with a simple sequential write and then read to an uncached 256 MB file. First is the file open time, in milliseconds. It should be at or near zero. The file write time in milliseconds is a true sustained transfer rate. CPU usage shows how much of the processor's time needed to be spent on setting up the transfers. Under bus mastering, this figure should be quite low. With PIO transfers, the CPU percentage will usually be in the 90% range. File flush time in milliseconds should be 0, as the writes were uncached. A non-zero figure shows that the controller is ignoring the "un-cached file" flag and is using the controller cache anyway. The rewind time should be zero as well, as this operation is simply a software pointer adjustment. The file read time in milliseconds is also a true sustained transfer rate, and CPU usage is again the amount of processor time occupied with performing the read. This value is very useful in comparing overall disk performance objectively. The CPU usage value is also very important, particularly for audio applications. With low CPU usage percentage values, we have more CPU cycles free for mixing, real time effects and other processing functions. Bus master drivers usually offer very low CPU usage values (typically below 2%). PIO mode wastes much more CPU bandwidth. File close time in milliseconds rounds out the sequential access part of the test.
The lines that follow contain measurements performed by accessing 8 files in rotating alternation using different block sizes for each read. This shows how larger read sizes dramatically improve performance . The files are each 16 MB long . BlockSize is the size used for the block read for each file. The test is run at 128K (131072 bytes), 64K (65536 bytes) and so on down to small 4K blocks. For each block size we get a total transfer rate in MBytes/sec that includes all overhead for doing an 8 file alternating read operation The track number is the total number of 44.1 KHz, 16 bit mono tracks that can be transferred. This assumes a DAW with no real time effects and that the software is written to effectively utilize the systems performance abilities. Finely we have CPU usage figures to show the processor overhead during the file transfers for that block size.
We have asked some of our friends to report their DSKBENCH numbers for various drives and mother boards. Click HERE to link to a chart of the results. You will note that we have recorded results only for the transfer rates and CPU usage figures for the 256 MB sequential write and read, and for the block tests only as far as the 32K buffer size as the other sizes are of marginal use.
Looking at DSKBENCH results, you can see how the total throughput decreases dramatically as the block size gets smaller. That's because of the larger time being wasted in seeks. Note that even at 128 K blocks, the throughput is much smaller than for sequential access, and the difference is because of the added seeking times.
Notice the entry for a DeskStar 5 drive on a Asus Super-7 motherboard. This is a rather poor performance spec for the sustained write throughput. The system is badly configured. That disk should read about 10 MBytes/sec instead of the 0.33 that is listed. This needs to be looked at! Also note that as a rule, reports for VIA chipsets show higher CPU usage that PIIX chip sets. This is shown here, too, although there are few entries for VIA among this data and it's a good bet in one case that bus mastering isn't engaged on this system.
Many folks have become skeptical of bus mastering results because of the way Intel has cheated on the reporting of performance using its bus mastering drivers. Standard benchmark programs that attempt to measure disk performance under business or server conditions were obtaining ridiculously over inflated performance figures due to Intel's behind the back use of memory for disk cache even after being instructed by the software to disable any caching. With other bus mastering drivers following the rules and Intel's not, this made it seem that Intel was the only company that knew how to write good drivers. This has been discovered and taken into account with newer benchmark programs including DSKBENCH, which uses the "flush" time to detect any underhanded activity, not that using cache would improve the results of streaming tests like the kind that DSKBENCH performs anyway.
|
|
Thu Mar 25, 2004 8:50 am |
|
|
|
|
hoggs33
Joined: 09 Feb 2004
Posts: 55
Location: Nottingham, England |
Got up to 172 tracks using a stereo file. Will try adding some plug in effects to see what happens. Below are the results of running the DSKBENCH program on my PC. Havn't really got a clue what it all means yet but will look at the article you posted to see if I can make some sense of it! 
Duncan
DskBench 2.12
(c) 1998, SESA, J.M.Catena (cat@sesa.es, www.sesa.es)
Timer Check = 1000 (should be near 1000)
CPU Check = 15.22 % (should be near 50.00 %)
CPU index (relative to Pro 200 MHz) = 6.156150
Open = 0 ms
Write = 5066 ms, 50.53 MB/s, CPU = 4.07 %
Flush = 0 ms
Rewin = 0 ms
Read = 5111 ms, 50.09 MB/s, CPU = 4.13 %
Close = 0 ms
BlockSize = 131072, MB/s = 9.98, Tracks = 118.63, CPU = 1.86 %
BlockSize = 65536, MB/s = 5.54, Tracks = 65.85, CPU = 1.97 %
BlockSize = 32768, MB/s = 3.00, Tracks = 35.65, CPU = 1.68 %
BlockSize = 16384, MB/s = 1.61, Tracks = 19.11, CPU = 2.08 %
BlockSize = 8192, MB/s = 1.20, Tracks = 14.26, CPU = 1.84 % |
|
Sat Mar 27, 2004 1:49 am |
|
|
iNSTiNCT2765
Joined: 05 Nov 2003
Posts: 60
Location: Denmark |
|
|
|
Deskbench
I used a mono track that was 3 minutes and 16 seconds long. I started copying it in Nuendo and at around 135 tracks, I could hear occasional clicks and there was also stuttering when I stopped the playing. At around 156 tracks, the clicks were very noticeable. In Nuendo, it says my buffer size is 128 Kb and there are 4 buffers. I know the latency of my soundcard is 10 ms at the setting I have now, when I switched the latency to about 62 ms I could handle way more tracks without the clicks, but this also makes my virtual synths delay when I play so that was no good. I used desk bench and here are the results. - Aman
DskBench 2.12
(c) 1998, SESA, J.M.Catena (cat@sesa.es, www.sesa.es)
Timer Check = 1002 (should be near 1000)
CPU Check = 50.04 % (should be near 50.00 %)
CPU index (relative to Pro 200 MHz) = 3.275259
Open = 0 ms
Write = 9574 ms, 26.74 MB/s, CPU = 1.40 %
Flush = 40 ms
Rewin = 0 ms
Read = 9544 ms, 26.82 MB/s, CPU = 1.73 %
Close = 0 ms
BlockSize = 131072, MB/s = 9.61, Tracks = 114.24, CPU = 0.53 %
BlockSize = 65536, MB/s = 5.21, Tracks = 61.90, CPU = 0.46 %
BlockSize = 32768, MB/s = 3.61, Tracks = 42.95, CPU = 0.61 %
BlockSize = 16384, MB/s = 2.72, Tracks = 32.30, CPU = 1.03 %
BlockSize = 8192, MB/s = 2.27, Tracks = 27.01, CPU = 1.65 %
BlockSize = 4096, MB/s = 1.91, Tracks = 22.70, CPU = 2.49 %
My computer is a 2 GHz, Intel Pentium 4 with 256 RAM and a 36 GB harddisk running Windows 2000. I don’t know the harddisk type and all that…I can’t find the spec sheet I got with the computer. |
|
Sat Mar 27, 2004 9:36 pm |
|
|
|
|
griff505
Joined: 23 Feb 2004
Posts: 68
Location: Bristol |
|
|
|
I used a stereo track of about 2 minutes 30 seconds long, and could manage about 150 tracks. I couldn't figure where to adjust the buffer sizes in Cubase SX2, but I could change the settings of my sound card which offered setting of high, medium, low and very low latency.
When DskBench was run from my Audio partition these were the results that I managed to scribble down:
DskBench 2.12
(c) 1998, SESA, J.M.Catena (cat@sesa.es, www.sesa.es)
Timer Check = 992 (should be near 1000)
CPU Check = 50.43 % (should be near 50.00 %)
CPU index (relative to Pro 200 MHz) = 11.742560
Open = 10 ms
Write = 25897 ms, 9.87 MB/s, CPU = 1.57 %
Flush = 220 ms
Rewin = 0 ms
Read = 5708 ms, 44.85 MB/s, CPU = 4.75 %
Close = 0 ms
BlockSize = 131072, MB/s = 16.20, Tracks = 192.60, CPU = 1.53 %
BlockSize = 65536, MB/s = 9.81, Tracks = 116.62, CPU = 1.85 %
BlockSize = 32768, MB/s = 7.18, Tracks = 85.37, CPU = 2.98 %
BlockSize = 16384, MB/s = 9.17, Tracks = 109.01, CPU = 4.27 %
BlockSize = 8192, MB/s = 8.21, Tracks = 97.66, CPU = 7.5 % |
|
Mon Mar 29, 2004 12:26 am |
|
|
|
|
All times are GMT. The time now is Fri May 16, 2008 4:32 pm
|
|
|
|
| |
