search

open-simh / simh

The Open SIMH simulators package
https://opensimh.org/
Other
476 stars 89 forks source link

PDP11: SET THROTTLE's meaningless response #308

Open al20878 opened 1 year ago

al20878 commented 1 year ago
pkoning2 commented 1 year ago

I wonder if the issue is that it hasn't executed anything yet, so it can't have a valid opinion about how fast it can emulate.

al20878 commented 1 year ago

hasn't executed anything yet, so it can't have a valid opinion

I should have been more clear, the simulator was run in between. I fixed that in the description. But it did state so too (albeit very implicitly):

But peak rate was: 17,039,580 instructions per second

The meaningless of the response was that I asked for 2 million instructions, for which I was barked at with the fat WARNING that it can't be done, and then the actual rate set by simh was 8 million. I mean, what's the problem then? And why was it giving me 8, even though I was asking for just 2? The "explanation" is totally screwed.

markpizz commented 1 year ago

Step back a bit and can you provide the whole magic that happened in the ... section below:

$ pdp11
sim> set cpu 11/70 256
...
sim> set throt 2m
al20878 commented 1 year ago

the ... section below

I was just using the simulator, nothing fancy

But the point here is why there's a warning at all with all the numbers laid out -- it's not even warranted. It could set 2m (it set 8m in the end, which it shouldn't, though, as I asked for only 2), so why the fuss?

markpizz commented 1 year ago

I was just using the simulator, nothing fancy

What were you using the simulator for?

What other sim> commands were executed in the ....

al20878 commented 1 year ago

What were you using the simulator for?

I don't really understand the question. I was running it with some software (XXDP, I believe, as that point), and then using Ctrl/E to interact with the simh prompt, etc... What else can I use it for?

al20878 commented 1 year ago

And ... again:

Assuming rate: 8,519,791 instructions per second

If it assumed (BTW, in what meaning, like in "take on" or in "suppose") 8 million, why did it complain about me asking for 2?

markpizz commented 1 year ago

I don't really understand the question. I was running it with some software (XXDP, I believe, as that point), and then using Ctrl/E to interact with the simh prompt, etc... What else can I use it for?

Expecting throttling to provide instruction execution pacing such that diagnostics seem to see execution rate and instruction timing they expect from the machine being simulated is absolutely not what throttling is capable of. @rms47 might have some comments about that. It might work for some things, but not the rigors of all diagnostics. Messing with the

Be sure not to attempt to use "SET CLOCK NOCALIBRATE" which exists in the https://github.com/simh/simh repo that will actually do what the diagnostics expect.

Assuming rate: 8,519,791 instructions per second

If it assumed (BTW, in what meaning, like in "take on" or in "suppose") 8 million, why did it complain about me asking for 2?

Also, throttling wasn't intended to be enabled and disabled and/or changed to different values on the fly. Some of this could possible, but the systems simh simulate all ran at a particular rate and never changed their execution speeds on the fly.

al20878 commented 1 year ago

SET CLOCK NOCALIBRATE which exists in the https://github.com/simh/simh

No worries, I won't ever touch simh/simh, so there's no danger for me to use that command

but not the rigors of all diagnostics.

It was NOT used for diagnostics per se; I used it in attempt to slow down the machine that simh simulated (and I suppose that's the intended use for that command).

different values on the fly

I was doing a boot in between, so why simh would bother? The software wasn't complaining a bit, only simh did.

but the systems simh simulate

You didn't mean the software, did you? 'Cuz simh simulates the hardware, last time I checked, so with a new boot, it's a fresh run, for all and any intents and purposes.

al20878 commented 1 year ago

But you digressed from the main point here of the WARNING that simh issues... It looks illogical, at best. It does not look helpful, either. Is it necessary at all?

markpizz commented 1 year ago

Throttling presumes that it is specified once before execution starts.

The host system might or might not be able to run at the specified rate, hence the message.

The logic could be enhanced to detect invalid sequencing of activities.

al20878 commented 1 year ago

Throttling presumes that it is specified once before execution starts.

Why's that? When simh is at its sim> prompt and until the simulation is started with the boot command or any other instruction executed, the simulator is not running, there's no simulated machine.

at the specified rate, hence the message.

It said the rate was 8mil, when I asked for 2mil, what's the problem?

detect invalid sequencing of activities.

And those would be what? What's invalid in exiting the simulation (with Ctrl/E), re-tuning your machine (like adding / removing devices, adjusting the CPU speed, etc) and starting it afresh (as with the boot command)? Why would you need to necessarily "quit" in order to do all that? I don't understand any reason behind this kind of policing the users.

markpizz commented 1 year ago

Like I said, the current logic presumes that throttling is is set before the simulator runs. No real systems could change execution rates without being rebuilt (which would be analogous to quit followed by starting a clean new configuration). If you want the restart you previously describe to work, maybe you could change the logic.

al20878 commented 1 year ago

Okay, but the WARNING still looks bizarre.

Honestly, I don't really understand why throttling can't be changed without quitting the simulator, like logically. It seems it'd be just a formula with the number of instructions to execute per second or something, adjusted by some multiplier.

deltecent commented 11 months ago

I have spent many hours trying to understand throttling. It works how it works and does seem to work quite well once the simulator has been running a while. I do wish throttling would take effect at boot, so software that depends on timing during boot would work, but that doesn't seem to be the case and I don't see that behavior changing.

markpizz commented 11 months ago

If throttling works for your system after it gets running, then you might get useful results if:

1) You enable the throttling rate you would prefer before booting, and start execution.
2) Once it has been running long enough for the internal measurement of your host system to actually run at the desired rate, halt the simulation (^E). 3) Look at the throttling details with "sim> SHOW THROTTLE". You should see a line in that output that looks like: Throttling by sleeping for: 2 ms every 2429 instructions 4) Change your startup logic to have a "SET THROTTLE x/t" command where x is the number of instructions in the above SHOW THROTTLE command and t is the number of ms in that output.

deltecent commented 11 months ago

Thank you! I will give that a try.

bscottm commented 10 months ago

@deltecent, @al20878: My interpretation of the latter part of this thread is, "SIMH doesn't converge rapidly toward the throttle rate." As Mark says, it will eventually, all things being equal, like external system load.

Reading through sim_timer.c, there's no control equation that governs updating the rtc delays to rapidly converge toward the throttle rate. In my experience, an exponentially weighted moving average or second/third order time differentials (*) are typical control equations. rtc->currd is updated using a simple time differential, which is why it takes longer to converge to a steady state, all things being equal. 2nd and 3rd order differentials converge toward steady state faster, if one believes basic control system theory.

Adding a control equation looks nontrivial, although one could experiment in sim_rtcn_calb and potentially simplify the code (i.e., eliminate checks for wild swings because the EWMA or differential already dampens them.) The subtlety is tuning the the EWMA's weight or the differential's constants.

(*) The third order time differential is officially named "jerk" (1st is velocity, 2nd is acceleration -- jerk dampens changes to the acceleration with a negative constant in the control equation.)