request for lock file parameter

[Mikus]

Back when it took more than one second per structure, I did not think about the client making continuous references to file "foldtrajlite.lock" -- to test whether the job should be stopped.

But now that it's several structures per second, I don't really want my hard disk being continually accessed at that rate. You already have the '-g ###' parameter to control the rate at which the "progress.txt" file is accessed. Could you please put in a similar parameter to allow me to slow down the rate at which the "foldtrajlite.lock" file is being accessed?

mikus

.

[m0ti]

Yeah, I've noticed my hardrive going like crazy too.

Now I understand why (checking if a file exists about 3-4 times a second). Probably should be settable from 1 to at least 10 structures. Might also get a small boost from that (not sure how much time it takes to do that IO, especially if the user is using the computer for even light IO activity).

[Kileran]

mikus, what OS are you running? most versions of windows will take care of this for you by monitioring the file via the FileSystem. i do 2.4 structures per second, but have no massive HD access like you fear.

although, i do run a Raid too. this may be why i dont have the massive HD access.

[Brian the Fist]

I have to agree with Kileran here. Any decent OS should not thrash the hard drive so what OS are you using, and what makes you think its thrashing the hard drive?

[Mikus]

Originally posted by Brian the Fist
I have to agree with Kileran here. Any decent OS should not thrash the hard drive so what OS are you using, and what makes you think its thrashing the hard drive?
I'm running SuSE 8.0.

I did not use the word "thrashing". What made me think of this is that on my front panel, the slot for the "disk access" LED is not completely dark when foldtrajlite is the only thing running. I guess what you are saying is that what is actually being performed is a software test (in memory) for the existence of an i-node, rather than a hardware access -- and that what I'm seeing in that LED slot is illumination from adjacent LED slots rather than an indication of disk access?

Stilll, being able to control the granularity of the test sounds like a good idea to me.

mikus

[runestar]

If you are using dfGUI (windows only), you can set the progress update to zero. At least that much you can control in terms of HD access. Of course doesn't make a very good benchmark at that point though. ;)

I don't remember what the switch is off-hand. Gotten spoiled on dfGUI, but I'm sure someone will point it out for us or you can look in the readme file. ;)

Incidentally if you don;t have at least 256MB of installed RAM when you turn on the extra RAM switch, you may notice DF thrashing the hard drive for a little whiles. This isn't really DF but memory being swapped out so it can accomdate DF. ;) If its still doing it after several minutes, likely you don't have sufficent RAM to handle loading all of DF into memory.

Best,

RuneStar½

[m0ti]

I'm not seeing any thrashing.

The HDD LED is always a flicker though while running DF.

[runestar]

Even with the extra memory switch on it still needs to read from and write to briefly from the hard drive at times. I believe there is a post somewhere on here from a whiles back from Howard that details exactly what is being written out.

Incidentally, clearing out the temp directory while DF is running makes bad mojo for DF, heh. ;)

RuneStar

[Kileran]

on a related note, a "No Disk Access" flag would be nice for people running the program on servers. disk access could slow down thier server's response time to mainstream files, depending on what thier server was actually used for.

thier are risks to using this type of flag on a machine though. if you used it and crashed at 99% of a run, you'd loose that information entirely. no chance of recovery. a flag like that should only be used by experts on stable machines.

[runestar]

Well, once again, we're back to the "only run this on machines you are authorized to." Common sense would tell you that if you have a concern about it running on a vital system, perhaps it be better not to.

Topping the stats chart is not worth losing a job for. ;)

In theory at least, running at the default priority, any disk access should have negligble impact as likely there are going to be more important tasks utilizing the CPU. And then, if the server is busy with other taks anyways, DF isn't going to get a whole lot of time anyhow.

Keeping it all in memory whether it be a switch or a RAM disk may not be a good idea because you have all that information being stored up in memory and then yes you don't have a possible impact from the disk hits, but then you got this big hog of a program in memory... disk hit seems to be a very minor inconvenience compared to keeping everything in memory until it finishes its current set.

RS½

[Kileran]

heh, i didn't mean running it on company servers. some of us run dedicated game servers for clan's/Guilds. servers like that are usually loaded with ram, and can afford to have the entire application buffered. your right, it's not worth losing a job over.

as far as the beneifits/risks arguments, i already stated that it would only be used by experts. it would just be a nice feature. everybody deserves options.

maybe i'l re-post this under the heading "would like to see this in the next client version" :cool:

[runestar]

Well, eventually its up to Howard if he wanted to code it. It comes down to a question of is it really worth the time to key in the extra code and test it for a few individuals.

To me it still seems the impact on disk performance is going to be negligble on your performance. Better than trying to keep a bunch of stuff up in your RAM. Seems stuffing your RAM witha host of tracking files and logs would be a bigger impact on performance. With DF on a low priority (I don't see running it at normal priority on a server for anything as that defeats the purpose of it) I don't see it as a concern on a decent gaming server. Now if you got a kick-ass server rig, it probably is a blip in the total disk access time.

The one possibility for concern I see is if your server isn't able to connect to the DF server for a day or so, and then you have all those being uploaded when it finally makes contact. At that point, bandwidth might also become a (temporary) issue as DF tries to send back all the results files especially as the files aren't compressable.


TTFN,

RuneStar½

[Brian the Fist]

Getting back to the original question. What you are asking for is more difficult to do than you may initially think. It is more important that the program exit very quickly after you remove the .lock file, with no chance of hanging or getting stuck. In order to make this 'customizable', it would also as a side effect make it possible to get stuck and not exit right away, and lead to other problems and headaches.

So as always I welcome your suggestions, but I am not convinced that this is worth the trouble it would cause (both me and users).

[runestar]

I agree with Howard. I've had command line apps that refused to die in Windows even with Task Manager.I don't know why, but it was just annoying as hell.

RS½