forums.silverfrost.com

[JohnHorspool]

Dan,

It gives incorrect result on my machine (64bit AMD Phenom quadcore) running XP64.

[DanRRight]

What it gives, current clock, max clock, other? You know clock frequency is varied by OS, right? Issue may appear when different cores are clocked differently.

[JohnCampbell]

John,

As you have found, it is not guaranteed for QueryPerformanceFrequency to give the processor frequency.
QueryPerformanceCounter and CPU_Clock@ appear to be based on the QueryPerformanceFrequency and most accurately give elapsed time. On reading the documentation for these there is no guarantee what the processor manufacturer does with updating these counters.

Another puzzle to me is why so many of the other system timing counters are only updated @ 60 hz. I tried to send questions on the MSDN Forums but never got an answer as to how to increase the update frequency. CPU_Time, date_and_time, Dclock@, GetLocalTime, GetTickCount and GetProcessTimes all appear to be related to this timer that is only updated 60 times a second. I don't know:
- where the 60 cycles is defined,
- how it could be changed, and
- what overhead would result.

I have written a routine to run CPU_Clock@ for .7 seconds (timed using dclock@) and calibrate the tick count, then store this in c:\processor_mhz.txt for other routines to quickly get. (I keep calling dclock@, noting when it changes value 41 times, indicating the start time of each cycle and call QPC each cycle)

If you want to differentiate between elapsed time and process (CPU) time, then GetProcessTimes gives some better info, but is only updated @ 60hz. It can be useful to differentiate between CPU or Processor time and disk I/O time, but achieving this changes with different processors, even different Intel processors !

If anyone can provide more information on this, I would love to know.

John

[DanRRight]

Related question:

As it should be expected. at some point i've got "disk full" and some crazy mess on the disk with 5000 empty tmp files. Great that more nasty things did not happen so i'd lose all the data gathered during last 4-5 months. That's tick data for all trades ever happened with each and every stock

Smart code has to predict that of course. What is the best way to find the free space left on specified disk drive using library functions ?

I'd do that by quasi-portable way using one or another OS commands built into all latest Fortran compilers like this

OScommand ='R:>dir >zzzOut '
call cissue@(OScommand,iOk)

and then analyzing last line in the created file zzzOut which usually end like this
13 File(s) 3,234,554,325 bytes
4 Dir(s) 4,454,872,832 bytes free

Any other way of doing that by invoking this compiler's huge library or WinAPI ?

(Let me know if you need something for your research or curiosity, no problem to sponsor our fellow fortraneers)

[JohnCampbell]

Dan,

I wrote a simple program to do what you suggested. One problem, this uses a temproary file so you will need to check when the disk is full that the file might not be created. What would cissue@ do in this case ? Also, are there other possible failures for cissue@ that are not due to a full disk.

[IanLambley]

Dan,
Are you trying to find the free space, then try this program which has a couple of methods.

[DanRRight]

Thanks John and Ian for ideas and solutions, they are very different valuable approaches.

As to the cissue, John, it is not completely clear to me yet when it issues an error status and when it does not. Definitely though when i heavily debugged it some time ago i've seen one case, i forgot right now exact details, will edit this post when remember, when i'd expect it to issue an error but it did not. So the idea is to get rid of it and use all other alternatives, may be even all of them for reliability

[DanRRight]

Ian, do i have to use both functions for arbitrary large partitions or just the second is enough?

[IanLambley]

Just the second

[JohnCampbell]

Ian,

The first call will give details for a disk of up to 8 terrabytes ! I think that is still a big disk.
Viewing the files will be an issue as Notepad struggles with files approaching 1gb. My line editor reads much quicker but tops out at 1.6gb (win32 again!!)

Incidently, your programing example sent me looking through the include files in the ftn95\include directory. Looking at the .ins files has driven me to writing a converter from 72 character fixed to 132 character free format so I can see the routine names and aliases as lists. It makes what looked like machine code look more readable.

John

[DrTip]

I know this one is a bit old now but it struck me at the time a more abstracted way of doing this would be to use a real database management system for data storage.

You would then use your favourite database communication technology to talk to the database.

The advantages are this. The people who have built the DBMS (microsoft, oracle) whoever have done lots of research into optimal database read write stuff, data integrity allow multi user access to data etc, etc.

The database can be put on a dedicated server and 1GB is a tiny database so will DBMS will make mince meat of it. eg SQL Server Express (free software) allows databases up to 12GB in size. DB2 is similar I believe. Don't know about MySQL.

Just a thought

Carl