Alan Sewards <alan.sewards@...>
As you know, I have been persevering with a single-machine setup, but
recently, I have been forced to make some changes. I thought you would be
interested in the results. I am running the 2.3.0a version of the
SkyStar2/Tellique software, MDM 188.8.131.52 and Animator 184.108.40.206.
I have been aware for some time that the wxsat machine has been
sluggish, with waits for the menus to pop up, jerky animations, etc. but it
all got too much last week and I checked out the Performance Monitor and
found to my horror that the pages writes per second were up in the hundreds
if not thousands! The Average Disk Queue was getting pretty long too but the
CPU was still handling things OK. So I decided to order another 512 MB RAM.
I expected that would arrive within a couple of days, but when it did not I
decided to connect my systems to run as a two-machine setup, with one PC for
the receive function and MDM, Animator, etc on the second. This proved to
have surprisingly little effect, the machine with MDM (but only 512 MB RAM)
was almost as bogged down as the single-machine had been, and as this
machine is my daily workhorse, this was not acceptable! Typical stats for
this (two-machine) setup are: Pages/sec: Avg 880, Disk Q: 2.5 Avg, CPU: 28
Avg. After a few days with still no new RAM, I changed back to the single
machine again (with 512 MB RAM). Stats for this were: Pages/sec: 1247 Avg,
Disk Q: 0.1 Avg, and CPU: 18 Avg. Finally the RAM arrived and I installed
it with these results: Pages/sec: 0.4 Avg, Disk Q: 0.009 Avg, CPU: 23 Avg. I
was surprised to find that the Commit Charge with 1GB RAM was still as high
as 404 MB, as the sum of memory needs for all processes did not seem to come
anywhere near 1024 MB. Snapshots later and following morning gave the
following: Pages: 3 Avg, Disk Q: 0.2 Avg, CPU 35 Avg; and pages: 0.4, Disk
Q: 0.005, CPU 18. Later I ran the Animator and the following resulted:
Pages: 0.4, Disk Q: 0.011, CPU: 27. Commit Charge went up to 490 MB. A bit
later (just after the big save at the end of a cycle) I got the following:
Pages: 578, Disk Q: 3, CPU: 78, but within a few seconds things were back to
the more normal figures quoted above.
My comments on these figures are as follows:
1. There is a HUGE difference between a machine with 512 MB and 1024 MB when
it comes to running MDM. With only (!) 512 MB RAM, the machine quickly
becomes bogged down in paging to disk, not perhaps to the point of losing
data, but certainly to the point of becoming a pain to use!
2. It seems essential that the machine running MDM has 1 GB of RAM. If it
does, and is fast enough (mine is Athlon XP2400+), it can handle as well the
receive function without noticing.
3. I don't understand why with 1 GB RAM, such a large Commit Charge is
required. Where is all this memory being used? MDM is shown as taking up
200-350 MB depending on when you look, but the sum total of all the other
processes running does not reach that figure.
Sorry this is rather long, but I felt the data might be useful and of
Best regards - Alan
web site: http://asewards.free.fr
David J Taylor GM8ARV 🏴 🇪🇺
Sorry this is rather long, but I felt the data might be usefuland of general interest.
Thanks for that. I haven't digested it all, by any means, but Sam
Elsdon has also been looking with Performance Monitor and I hope he
write up his findings!
- ensure that you minimise the number of HRIT channels you collect.
Only collect what you need.
- Don't take LRIT if you don't need it.
- be sure to defrag your disks regularly
- use NTFS and not FAT for the disk structure.
Having said that, with the current beta version I am currently
collecting all 12 channels, and I see a Commit charge in task
manager of 530MB as I write. In addition to the MSG Data Manager, I
- Internet Explorer
- Speaking clock
- MRTG (runs under Perl)
- Outlook Express
- Front Page
- Zome Alarm
I often run Borland's Delphi for development, and various office and
imaging products as part of the development process. All this under
Windows XP SP1. The machine only seems to be affected by saving the
HRV image (in JPEG format), and I'm almost sure it didn't used to do
that, and suspect that one of the security patches is responsible.
Saving an HRV image in PNG format does take time - I've just been
doing that as part of the current "lossless HRV" tests.
I don't see why you are quite so worried by the commit charge value
you are seeing.
As to your recommendations, I believe the Web site already says to
have 1GB if you want to process HRV (channel 12) data, you fidings
do support that.