Void's Forums

With the cable being down and nothing better to do it did give me some time to play around with the 2.5 kernel. I had just downloaded a copy of 2.5.61 and it took me quite some time to figure out how to get the thing so it would boot. I need to upgrade to this kernel so my uptime doesn't roll over at 497 days. :) I have been playing around and realized that the jiffies variable now rolls over ever ~49.7 days rather than ~497 days. The nice part is the uptime no longer rolls back to 0 when this happens. It just increments another variable. So I can bump up the uptime in 49.7 day increments by just setting the jiffies variable to "-1" and let it roll over, for every time I set it to "-1" it will add 49.7 days to the uptime. Now I have to figure out a way to do this so it doesn't hose other stuff up then it's going under the hood of the Void server.

[edit]
Please read the rest of the thread before commenting. I do have a lot of false information in the first several messages. Thanks!
[/edit]

Guess the server was down in the morning......I was trying and squid gave some resolve errors...Good thing the server is up and running!

007

Actually the server wasn't down, my cable connection was down.

are any of the 2.5 kernel series actually usable/stable or is it best to just stick with 2.4.20, what new features do the 2.5 kernel series have???

All I can say is, 2.6 will be a real joy. Compiling isn't as much of a pain in the arse as far as how much has to be recompiled when adding/removing drivers. Much faster to rebuild a kernel (as long as you don't go doing a "make clean" every time).

Now having said that, I had a pretty rough time getting all the pieces together and getting the kernel compiled to where I could actually boot it, and I consider myself much higher than a novice, but far from being a kernel hacker (although I do hack at it occasionally). So I would say stick with 2.4 (upgrade to 2.4.20 from source would surely be recommended), but I wouldn't mess with 2.5 or even 2.6 until a distro ships with it which I feel is probably another 8 months to a year away. That is unless you just want to learn, then go for it. Just keep in mind that you will not get nVidia drivers or any other proprietary drivers to work on a development kernel (at least expect a fight).

Ok, all upgraded to the 2.5.61 kernel:

Code: Select all

[voidmain@nitro voidmain]$ uname -a
Linux nitro 2.5.61 #2 Mon Feb 17 00:23:50 CST 2003 i586 i586 i386 GNU/Linux


The site was probably down for about an hour although it really only required a reboot to bootstrap the kernel which "could" have resulted in only around 5 minutes of downtime. But I wanted to boost my uptime to where it was and see if it goes through the rollover properly. Getting the uptime up to 497 days took about an hour. Patch for 2.5.61 and script to boost your uptime are located here:

http://voidmain.is-a-geek.net/files/uptime/

Have fun!

And now I downgraded it back to 2.4.20. Everything looked great with just some minor annoyances that I had to work around. I had bumped up the uptime to 497 days and planned on having Netcraft show me roll through the 497 day uptime barrier when I decided just out of curiosity what an nmap scan would look like. To my horror it only showed that the system had been up for .035 days (the *real* time obviously). I guess it's back to the drawing board. This works fine on the 2.4.x kernel and when I type uptime on both 2.4.x and 2.5.x it shows the boosted numbers but only 2.4 shows the boosted numbers externally, up to 497 days that is. Now I'm mad! :)

Ok, this site is now running on kernel 2.5.61 along with my newly created uptime patch for 2.5.6x. I have the uptime set to just over 497 days which is just past the point where 2.4 kernels and below used to roll over to 0. It seems that at 496 days an external "nmap" command will show the system has been up 496 days, yet setting it to just over 497 days nmap will now "0.x" days. That is, nmap seems to roll over. I don't know for sure if this is a problem with nmap or if there is an issue in the TCP/IP stack in Linux 2.5.6x. I'll try and get to the bottom of it. I'll bet that netcraft will also roll over. We'll have to wait a couple of days to see what happens.

sysinfo

Void Main, what I want you to do is completely mess with the people at netcraft. All you have to do is raise your uptime to be higher than that of the highest server there. Then declare to everyone, including the people at netcraft what you did. By the way change your server signature back to linux too. By the way, Im just now getting my server up to 100 days of actual uptime, not this cheating stuff.

Well, I would like to try this (maybe not jack it up to be the highest but at least bump it to over 500 days). The uptime right now is around 498 days which is just over the old limit of 497 days. The "uptime" command properly reports 498 days, however an "# nmap -sS -O voidserver" shows the uptime having wrapped back to 0 (well it's up to 1 now). I believe this would also mean that Netcraft will only see the machine as having 1 day of uptime. I have to wait for the next time Netcraft takes a reading on me to be sure.

If netcraft only shows me having 1 day of uptime then there are 2 or more possibilities:

1) nmap is broken (and I am assuming that Netcraft uses nmap code to determine uptime).
2) TCP/IP in Linux is broken and needs to be fixed relative to the local uptime fix (~ jiffies -> jiffies_64 + HZ 100->1000 + etc).

I believe the problem is in the area of #2 above. I haven't started digging into the problem. It will take much research on nmap code and the Linux TCP/IP code, something that I have tried to grasp with minimal success in the past.

I have been reluctant to post a message directly to the kernel mailing list but I do believe if it is an issue that needs to be solved before the release of 2.6 or there are going to be some disappointed people 497 days after installing 2.6 when Netcraft drops them back to zero uptime, similar to the disappointed people with any other Linux kernel who can only get 497 days of "reported" uptime out of it (many have much more than 497 days "actual" uptime).

Code: Select all

[voidmain@nitro voidmain]$ uname -a
Linux nitro 2.5.62 #2 Thu Feb 20 11:17:25 CST 2003 i586 i586 i386 GNU/Linux
[voidmain@nitro voidmain]$ uptime
 04:51:29  up 498 days, 19:21,  1 user,  load average: 0.45, 0.27, 0.27


Ok, little more information. The problem is much worse than I though. It appears that nmap determines the uptime of a machine based on the TCP timestamp (see RFC 1323). A little more research and a little playing with "tcpdump" verifies that the timestamp is a 32-bit number. This number appears to max out at 49.7 days rather than 497 days like with the old "uptime" problem. This is because in the new kernel HZ has been moved to 1000 rather than 100 so that's OLDLIMIT/10.

The reason there was a limit of 497 days on 32 bit Intel machines is because the system time was kept using a 32 bit variable called "jiffies". Basically the calculation was 100 jiffies per second. The maximum value that an unsigned 32 bit variable can hold is 4294967295.

4294967205/100/60/60/24 = ~497.1 days

On the new system HZ=1000:

4294967205/1000/60/60/24 = ~49.71 days

I assume that Linux used to get the TCP timestamp value using the same calculation. I also assume that it continues to get the timestamp using the same calculation. Now, time to track down where the timestamp is set in the kernel and seeing how difficult it may be to "fix" it. People are going to be pissed when all of a sudden the longest uptime on Netcraft fro Linux boxen is 49 days. :)

Hmmmmm there is an alpha doing 1000+ days of uptime on uptimes.wonko.com

X11 wrote:Hmmmmm there is an alpha doing 1000+ days of uptime on uptimes.wonko.com

Is it running Linux? This is only a Linux problem. If it is running Linux then the uptime is faked. You know how easy it is to fake a stats site that relies on a client to give the uptime.

Gee never knew voidmain was such a prankster.

X11 wrote:Gee never knew voidmain was such a prankster.

What do you mean?