TUI lag

[System123]

Hi

I have just finished my basic console driver and keyboard driver. However when i test it in bochs it runs perfectly. But when i boot it on my pc it lags. I can see the screen refresh at a very slow speed and the text i type takes forever to show. Y is this?

[cr2]

What computer are you running your OS on?

[01000101]

are you using any timers for any of the video display or keyboard drivers?
BOCHS sometimes runs with an insanely fast timer, and if you tweaked any settings for your operating system to appear 'normal' in BOCHS, may infact have an inverse effect when used on real hardware.

[sebihepp]

Hello,

try to change the following line in bochs-source.txt:
clock: sync=both, time0=local
This means bochs is using the clock for synchronisation.

Greetings Sebihepp

[System123]

Im running it on a intel celeron dual core 3.2ghz. With 1gig ram. Could my PIT timer have anything to do with this? The timer is used to measure up time and its hz = 100? Is there a way to make this more efficient?

[Brendan]

Hi,

I have just finished my basic console driver and keyboard driver. However when i test it in bochs it runs perfectly. But when i boot it on my pc it lags. I can see the screen refresh at a very slow speed and the text i type takes forever to show. Y is this?

Im running it on a intel celeron dual core 3.2ghz. With 1gig ram. Could my PIT timer have anything to do with this? The timer is used to measure up time and its hz = 100? Is there a way to make this more efficient?

Is it only text you type that takes too long to be seen, or is it all text (is the lag related to keyboard input or is it video related)?

How do you use the timer? For example, maybe you check if a video buffer has changed every 10 ms and update the display if it has, or maybe you don't use the timer for the video at all but do use it for the scheduler (e.g. a "round robin" scheduler where each task gets 10 ms in turn, and if theres 100 tasks it takes 1 second before the console task gets CPU time).

Are your device drivers implemented as separate tasks that need to be scheduled? If so, how does the scheduler work - does it respect task priorities, and will it pre-empt a lower priority task if a higher priority task becomes ready to run (so that your device driver tasks can have higher priority and never wait for a lower priority task to use their full time slice)?

Are there any re-entrancy locks that could be involved? For e.g. a lock on the video, where the console needs to wait for some other task to free the lock before it can get the lock and update the video? If so, how are they implemented, and how do they interact with the scheduler?

How does your video interface work? For example, do you send entire frames to the video driver to display, and if you send 10 frames at the same time will it display all of them one at a time or will it only display the most recent frame and skip the rest?

There's lots of different reasons for laggy user interfaces...


Cheers,

Brendan

[System123]

The keyboard isn't the problem as when I type I can see the characters coming onto the screen it is only every couple of characters I can see a refresh line running down the screen. The timer just is used as a stopwatch to keep track of kernel up time.

[salil_bhagurkar]

What is this refresh line... Is it the characters refreshing?

[01000101]

it really does seem like you are making a full video screen buffer and copying it to video memory all at once, all (80*25*2) bytes.

Does it happen when you type very slowly, like one key every few seconds? if not, then maybe your key->vid code is just inefficient at handling fast input.

[System123]

Problem solved.

My problem was actually quite simple. When i initialised the PIT i changed the hz to a 100. However in my code i accidently typed 1000 this means that the interrupt fired 1000 times a second with my timer code firing 10times a second. So this left very little time for the cpu to handle graphics.

[salil_bhagurkar]

Wtf? I had once set the PIT to 10000 Hz and even my scheduler worked fine. There was no question of lag in the screen display.

[System123]

Ok that is strange. I changed my PIT to 100Hz and everything works perfectly now Wierd stuff

[Brendan]

Hi,

I changed my PIT to 100Hz and everything works perfectly now Wierd stuff

There's a major difference between "everything seems to be working" and "everything works perfectly".

For example (assuming a 2 GHz CPU for simplicity), if a timer IRQ handler is so slow that it consumes 1 million cycles, then at 1000 Hz it'd consume 50% of the CPU's time and cause noticeable lag everywhere; but at 100 Hz it'd only consume 5% of the CPU's time and the lag may not be noticeable. However, regardless of whether the lag is noticeable or not, the timer IRQ handler would still be far too slow and still needs to be fixed. This is partly because on a 200 MHz CPU it'd still be using 50% of CPU time, and partly because (even on modern/fast computers) the IRQ latency would be unacceptable even if the lag can't be noticed by the end-user.

Maybe what you did was hide the symptoms of a potentially serious problem...


Cheers,

Brendan

[System123]

HAHA well I didn't hide them well. The problem still exists. Especially when I use may backspace algorithm. Download my code from http://code.google.com/p/gizmicos/downloads/list

[Brendan]

Hi,

HAHA well I didn't hide them well. The problem still exists. Especially when I use may backspace algorithm. Download my code from http://code.google.com/p/gizmicos/downloads/list

I took a look...

The only bug I can see so far is that the backspace code does "Dec(CursorPosY);" without checking if CursorPosY is zero, which means CursorPosY can become negative (if CursorPosY is signed) or overflow (if CursorPosY is unsigned) and you end up trashing data that isn't on the screen.

Mostly the console code is severely unoptimized.

For example, every time you print one character or move the cursor you call "Blink" which does four I/O port accesses; so if you print a string of 50 characters you do 200 I/O port accesses. I/O port accesses are very slow, and you'd only need to do four of them for a string. However, it's better to turn the blinking cursor off and leave it off (and let whatever code is using the console turn the blinking cursor back on only when it's needed) so (for e.g.) they can print several strings and then turn the blinking cursor on again and only have one set of I/O port accesses (or perhaps they could do 2 strings, one character, then a decimal value, then another character, then turn the blinking cursor back on, etc).

It'd be a good idea to maintain "Offset" instead of recalculating it every time, partly because recalculating "Offset" involves multiplication (which is a little slow).

If you move the cursor several lines past the bottom of the screen and then backspace a lot until the cursor is back on the screen, then you don't need to do any scrolling at all. If the blinking cursor is off, then you only need to scroll if the cursor is past the bottom of the screen and you want to print a visible character (which doesn't include invisible stuff, like tab, space, newline, etc).

I did an example (attached) to show you. I've never written Pascal code before and I didn't try to compile it or test it, but it should give you an idea.

Lastly, you should be using a video buffer in RAM and then copying data from the buffer in RAM into video display memory when whatever code is using the console tells you they're ready (probably when they turn the blinking cursor back on). When you copy the data from the buffer in RAM into video display, you only need to copy data that changed. One way to do this is to have an array of 25 flags (one flag per screen line) - you set the corresponding flag if the screen line is changed (e.g. "lineChangedFlags[CursorY] = 1"), and only copy changed screen lines from the buffer into video display memory if the corresponding flag was set. That way you could send 50 GiB of data to the console and only 25 lines of it to would be sent to video display memory...

That only leaves one problem. For most good consoles the user can scroll back up the screen to see stuff that disappeared. For most Unix clones you can use "shift + pageUp/pageDown" and/or "shift + cursorUp/cursorDown", and usually there's 400 lines or more kept for the user to scroll through. There's an easy way to implement this - just make the video buffer in RAM larger than display memory, and only copy 25 lines of the buffer into display memory.


Cheers,

Brendan