MRO wrote to deon <=-
rig up a daily reboot. I do it for all my bbses. that will fix a
lot of issues that may pop up.
Is there a way to "busy out" the polled node, so another thread doesnt try and call it again?
The SBBS event thread is a single thread. BinkIt polling is normally done as a timed event, which is run as in the foreground of
that single event thread. So I'm not clear what "another thread" would be.
rig up a daily reboot. I do it for all my bbses. that will fix a lot of issues that may pop up.
but don't listen to me, i have great uptime for decades and my shit always w
irc 0.07% 271.7MiB 6.91% 162MB / 739MB 20.5kB / 90.1kB
bbsweb 0.11% 9.023MiB 0.23% 42.3MB / 110MB 500kB / 90.1kB
ecweb 0.06% 282.9MiB 7.20% 205MB / 3.14GB 105MB / 467kB
rmweb 0.06% 67.22MiB 1.71% 36.8MB / 246MB 28.1MB / 90.1kB doorparty 0.00% 5.055MiB 0.13% 29.2MB / 25MB 6.37MB / 0B
System is mostly idle, most of the time. Nothing is really crazy, the
web instances seem to use the most resources, which are kind of
expected... Slightly surprised how much memory the IRC service uses on
its' own, but not crazy either. I'd thought about breaking nntp off
Today I discovered SBBS with 2 threads both running at 98% CPU
- having stopped and restarted SBBS, its all back to normal.
Re: Re: CPU Hog
By: dragon to MRO on Sat Aug 06 2022 03:28 pm
>
> Some people are interested in WHY something breaks instead of just in a
> quick "fix". It's called "debugging". I would think in your years of
> experience you'd have heard of it. ;-)
I absolutely know WHY something breaks normally. It's just good to reboot once a day to clear up issues that come up randomly. That's how bbses are. shit happens. We are usually running windows and launching legacy software made by hobbyist programmers. We can't be around all the time when something decides to go haywire and if a user can't connect one time they may never try again.
You aren't a sysop, so you wouldn't know that; you just run a website that scriptkiddies scrape to attack us.
---
� Synchronet � ::: BBSES.info - free BBS services :::
Re: CPU Hog
By: MRO to Nightfox on Sat Aug 06 2022 04:33 pm
MR> but don't listen to me, i have great uptime for decades and my shit always
MR> works.
If you have it reboot every day, then it's not up continuously for more than a day. I wouldn't call that great uptime.
I've been running a BBS since 1994 (with DOS at the time), and I didn't have to reboot my BBS machine every day to keep things working (and still don't).
---
� Synchronet � Digital Distortion: digitaldistortionbbs.com
you haven't been running it every day like i have.
and i don't HAVE to reboot. I just do just to do some cleanup. shit happens with old doorgames and legacy programs.
if you want to measure dicks, here's my vm host uptime. i only rebooted
it because there was a network issue with ovh and i was trouble shooting.
What did your RAM usage look like? I've seen a similar issue a couple
times, where I couldn't connect on the mail service port... I don't know what part of Synchronet was causing the issue... there was definitely
some kind of memory leak as I was getting a lot of out of memory errors.
but if you're running a bbs, and you have dos games and shit you
should be running it on windows 32bit instead of emulating shit
in a linux environment. it's easier and it's the right tool for
the job.
It's quite easy to run that stuff on Linux if you know what you're
doing, which you clearly don't. It's simple. It works perfectly. It doesn't require a daily reboot to keep it running.... Hahahahahaha
ntvdm64 is a software emulator they borrowed from windows for.. powerpc?
another neat thing is each ntvdm gets it's own "640k" of ram, it's own EMS/XMS, etc.. it's really the scaffolding of the single-pc multinode
bbs.
it's neat stuff. bit of a shame the 16bit mode is not accessable from 64bit oses.. but we're lucky it works in 32bit mode. in theory it should be faster than the ntvdm64 one, but with modern cpus i don't know if you could measure that difference anymore
On 08-08-22 19:49, fusion wrote to Nightfox <=-
On 08 Aug 2022, Nightfox said the following...
As far as I can tell, NTVDM64 is meant to work on 64-bit Intel/AMD processors. Where did you see that it was for PowerPC?
an excerpt from the ntvdm wiki:
Since virtual 8086 mode is not available on non-x86-based processors
(more specifically, MIPS, DEC Alpha, and PowerPC) NTVDM was instead implemented as a full emulator in these versions of NT, using code licensed from Insignia's SoftPC.
On 08-09-22 00:30, Ryan Fantus wrote to fusion <=-
another neat thing is each ntvdm gets it's own "640k" of ram, it's own EMS/XMS, etc.. it's really the scaffolding of the single-pc multinode
bbs.
Wow, I had no idea. That's pretty neat. Honestly, I use Windows 7 32
bit for my doorgame host and it works astonishingly well. No slowdowns
or any other apparent issues. Only some games like Yankee Trader don't work; everything else seems to hum along as expected.
it's neat stuff. bit of a shame the 16bit mode is not accessable from 64bit oses.. but we're lucky it works in 32bit mode. in theory it should be faster than the ntvdm64 one, but with modern cpus i don't know if you could measure that difference anymore
On 08-09-22 16:22, Daryl Stout wrote to Tony Langdon <=-
That was fun running a DOS based dial-up BBS under DOS 5 with
DESQView, and experimenting with the QEMM Memory Utility. :P
However, Quarterdeck Software (which made DESQView and QEMM), as well
as TeleGraphix (which pioneered RIP Graphics), are both long gone now.
That's the magic of virtual 8086 mode. Same happened with DESQview on a 386, every session got its own 60k (less any OS/TSR overhead loaded before DV). And OS/2 really made good use of virtual 8086 mode with its DOS subsystem - the "better DOS than DOS".
That was fun running a DOS based dial-up BBS under DOS 5 with DESQView, and experimenting with the QEMM Memory Utility. :P
However, Quarterdeck Software (which made DESQView and QEMM), as well
as TeleGraphix (which pioneered RIP Graphics), are both long gone now.
Sysop: | Coz |
---|---|
Location: | Anoka, MN |
Users: | 2 |
Nodes: | 4 (0 / 4) |
Uptime: | 06:10:59 |
Calls: | 93 |
Files: | 4,554 |
Messages: | 215,409 |