Author Topic: time() problem in mudos  (Read 5360 times)

Offline Nulvect

  • BFF
  • ***
  • Posts: 127
    • View Profile
time() problem in mudos
« on: March 10, 2011, 06:34:52 pm »
So our hosting provider just updated us from a 2.4 kernel to a 2.6 (without asking), and now time does not proceed in our mud. It's MudOS v22.2b14, but I tried with fluffos 2.21 and it has the same problem.

I tracked it down to the unix time() function which is used to get the current time in mudos and, I presume, fluffos (have not checked fluffos source code yet). You can "man 2 time" in linux to get the man page on this C function.

MudOS port.c, lines 69-72:
Code: [Select]
int get_current_time()
{
    return (int) time(0l);      /* Just use the old time() for now */
}

Seems simple enough, right??

Anyone have any clue why this is not working anymore??

Offline mactorg

  • Acquaintance
  • *
  • Posts: 30
    • View Profile
    • DarkeMUD
Re: time() problem in mudos
« Reply #1 on: March 10, 2011, 07:13:15 pm »
I am running Linux version 2.6.32.9-60.fc12.i686.PAE with gcc version 4.4.3

our time is running fine with the old MudOS v22.1b22 and fluffOS 2.22 on our test lib.

running Fedora version 12.

MacTORG
to live is to learn, to die is to graduate.

http://www.darkemud.com

Offline Nulvect

  • BFF
  • ***
  • Posts: 127
    • View Profile
Re: time() problem in mudos
« Reply #2 on: March 10, 2011, 09:00:24 pm »
Thanks for the info, Mactorg. It just ocurred to me that this may be caused by running a program compiled for 32-bit hardware on a 64-bit machine. I will try compiling the latest fluffos from scratch later today.

Offline Nulvect

  • BFF
  • ***
  • Posts: 127
    • View Profile
Re: time() problem in mudos
« Reply #3 on: March 11, 2011, 12:21:05 am »
Well, that didn't work.

RedHat 9
kernel 2.6.27.41-20091211a
gcc (GCC) 3.2.2 20030222
GNU Make (gmake) version 3.79.1
FluffOS 2.22

Compiles fine, copied the lib over, same problem.

I will try compiling a new kernel myself I suppose...

Offline Nulvect

  • BFF
  • ***
  • Posts: 127
    • View Profile
Re: time() problem in mudos
« Reply #4 on: March 11, 2011, 04:10:43 pm »
I found something more on this. SIGALRM is not happening when scheduled by the backend() func. I can do kill -ALRM <driverpid> to make heartbeats happen. Does anyone know if this might be related to the Tickless Kernel option in 2.6 kernels?

Offline wodan

  • BFF
  • ***
  • Posts: 434
  • Drink and code, you know you want to!
    • View Profile
Re: time() problem in mudos
« Reply #5 on: March 11, 2011, 04:51:04 pm »
Does the time change at all on that system? sounds like it doesn't!

Offline Nulvect

  • BFF
  • ***
  • Posts: 127
    • View Profile
Re: time() problem in mudos
« Reply #6 on: March 11, 2011, 06:44:17 pm »
It does. Both date and uptime commands work fine in the shell, and I compiled a little test program in C that just prints out the value from linux's time() func and that changes as expected.

Offline Nulvect

  • BFF
  • ***
  • Posts: 127
    • View Profile
Re: time() problem in mudos
« Reply #7 on: March 12, 2011, 02:57:24 pm »
Another admin on the mud figured it out. MudOS calls ualarm() in backend.c with whatever value you set the heartbeat interval to, but ualarm() now errors when trying to use any value greater than 1000000 (1 second). Unfortunately, even after fixing this, MudOS started segfaulting. FluffOS does not seem to have this problem, so we're now (finally!) on a current driver. Yay!

Sidenote: the documentation in local_options in FluffOS indicates that the heartbeat interval is in microseconds, when in fact it is in full seconds.

I'd make some diffs but it seems like the FluffOS team already fixed this problem. Go fluffers!

Offline wodan

  • BFF
  • ***
  • Posts: 434
  • Drink and code, you know you want to!
    • View Profile
Re: time() problem in mudos
« Reply #8 on: March 13, 2011, 11:06:01 am »
so it wasn't time() at all? :)

Offline Nulvect

  • BFF
  • ***
  • Posts: 127
    • View Profile
Re: time() problem in mudos
« Reply #9 on: March 14, 2011, 09:26:38 pm »
Sometimes things are not as they seem.

Offline quixadhal

  • BFF
  • ***
  • Posts: 642
    • View Profile
    • WileyMUD
Re: time() problem in mudos
« Reply #10 on: March 15, 2011, 12:53:25 pm »
Actually, that brings up a good question though.  Is there any technical reason why the heartbeat interval can't be specified in microseconds?  In the days of yore, the idea of a sub-second heartbeat was laughable, but with the kind of hardware we throw away these days... if you really WANT a 1/4 second heartbeat, why not allow it? :)

Same goes for call_out delays...

Not saying it's a great idea, but, if it's easy-peasy, it might be a nice option.

Offline wodan

  • BFF
  • ***
  • Posts: 434
  • Drink and code, you know you want to!
    • View Profile
Re: time() problem in mudos
« Reply #11 on: March 15, 2011, 03:20:20 pm »
doesn't really fit in the current way the driver does things,
the thing living on my harddisk as fluffos-3.0 does do that though, but it crashes, misses call_outs and relies on c++ and threads.

maybe some day :)

Offline Holyavenger

  • Friend
  • **
  • Posts: 92
    • View Profile
Re: time() problem in mudos
« Reply #12 on: April 18, 2011, 11:35:00 pm »
Actually, that brings up a good question though.  Is there any technical reason why the heartbeat interval can't be specified in microseconds?  In the days of yore, the idea of a sub-second heartbeat was laughable, but with the kind of hardware we throw away these days... if you really WANT a 1/4 second heartbeat, why not allow it? :)

Same goes for call_out delays...

Not saying it's a great idea, but, if it's easy-peasy, it might be a nice option.


Good point, in fact alot of these values almost seem moot in lieu of the more potent hardware. I remember trying to get enough lower mem free (640k) to get my lp mudup on a dos machine in 1989