Re: not yet perfect, but...

Ulrich G. Kliegis
 

Yes, Ulrich, I can see the events on your graphs. Be careful with
multiple partitions on the same disk. If the disk head needs to move
half way across the disk to access the other partition, that could be
a greater penalty than having those files just one the same partition.
Yes. I thought about moving the virtual memory to the RAM disk, but then,
after some deep thinking... :)

Nope, not really.
I have a SSD on one of my new systems in the office, but that's reserved for
other stuff.

Using two physical disks is a much better solution - perhaps system
files and my software on one disk, EUMETCast and processed data files
on a second disk. In any case, get a disk with good performance - with
a 32MB or 64MB buffer.
See, I have three HDDs: C: has system and your software, D: only things
like setup-files, E: all MSG stuff (including the MSG-related receiving- and
received folders, F. the same for NOAA-AVHRR and Metop.

FSY of course on the RAM disk.

I would recommend having a real-time defragmenter running - with the
TelliCast 2.4.4 client software we have found mstDefrag to be very
acceptable, and have almost zero effect on received data (i.e. we
could not attribute any extra losses to running the defragmenter).
I've used version 2 and 3, but I see they are up to version 7 now.
How did they manage that?
Too many software fragments... :)

And since Windows 7, it's a fashionable must to have some 7 in the brand.

I follow the not more than a few steps at once strategy now, installed an
older mst defrag that I still had here (3.6) and started it. Well, it's doing its
work, and you all can see of it will decrease the missed packets count. The
degree of fragmentation on E: and F: was considerable...




http://www.mstsoftware.com/mst-Defrag
Both will defrag "when needed" by monitoring the disk state.
Auslogics will defrag no more than once per 12 hours, and Smart Defrag
not more than every three hours. If you haven't defragged your disk,
that could be the issue.
mst reagards idle times - although these do not really happen, but it seems
to stay rather politely in the background.

From the TelliCast configuration standpoint:

- you have checked that the FSY files are actually on your RAMdisk, I
suppose? But judging from your FSY graph they must be!
Well, I suppose they are the reason for the FSY files growing (after the
reboot last night) - there is no other explanation.


- I recommend using the common tmp_directory entry in the recv.ini
file, rather than individual entries in the recv-channels.ini file -
it is cleaner and makes the channels file simpler. Something like:

______________________________
[parameters]
tmp_directory=temp
______________________________
My rationale was: If I dispatch the data already in the beginning to the
correct partition, they don't have to be pushed around again. And the disk
heads have it a bit easier, maybe.


The directory should be on the same partition as the \received\
directories. As Alan mentions, all this should be /outside/ the
Program Files tree. I installed to C:\EUMETCast\ in one Windows XP
installation. My recv-channels.ini file then has lines like:
Like in my case, see above.


Thanks again,

cheers,

U.

Join MSG-1@groups.io to automatically receive all group messages.