KVCD in Linux

russiansexpat · #1 12-05-2003, 01:38 AM

http://www.kvcd.net/forum/viewtopic.php?t=7771

rendalunit · #2 12-31-2003, 02:40 AM

What is the reference to year 2038 about?

Just wondering,
thanks

Dialhot · #3 12-31-2003, 05:18 AM

Quote:

Originally Posted by rendalunit

What is the reference to year 2038 about?

A lot of programs are coded in C or C++ language. In these (and others language) time and date are coded as number of second spent since the EPOCH (the time reference that is 01/01/1970).

Since the time is coded on 32 bits, you can have only 2^32 seconds before to have a general reset of all time based programs ! And the lethal date is in 2038 (you can count

)

Thats will be a HUGE bug, far larger than the Year 2K one.

rendalunit · #4 12-31-2003, 12:27 PM

ah Thanks

That does sound like a bad bug

Dialhot · #5 01-01-2004, 09:45 AM

Quote:

Originally Posted by rendalunit

That does sound like a bad bug

Not really : the 64bits CPU are coming and before 2038 they probably be 128 or 256. All the program will be compiled in 64 bit mode at least and the reference size for an integer (that is set to 32 bits nowaday) will be probably fixed to 64 bits also. So the 2038 problem will disappear.

ak47 · #6 01-01-2004, 11:57 AM

Kinda sounds like a scam to get out of 32-bit CPUs. To bad that the date isn't closer, since 64-bit now is out.

russiansexpat · #7 01-06-2004, 08:57 AM

Hopefully technology change before 2038.
Still we are flying on average 30 years old airplains.
Just to recomple application programs is not always possible - source code went to trash bins and developers gone fishing or do some gardering.
2^31+1 in fact in kernels, not like in Y2K applications and these kernels in many situations are embedded.
Somebody will have some fun around 18 January 2038, especially because most of the teens nowdays have no idea even how electricity works.

Dialhot · #8 01-06-2004, 09:17 AM

Quote:

Originally Posted by ak47

Kinda sounds like a scam to get out of 32-bit CPUs. To bad that the date isn't closer, since 64-bit now is out.

Don't worry about that : we are already doing all our applications in 64 bits. And I do not think my company is the only one to do that

ak47 · #9 01-06-2004, 03:50 PM

Thats your company, but there is no video game for the pc yet that supports 64-bit, I think, also barly any 64-bit video encoders.

BobNET · #10 01-06-2004, 04:30 PM

Quote:

Originally Posted by ak47

but there is no video game for the pc yet that supports 64-bit, I think, also barly any 64-bit video encoders.

Chicken and egg problem... very few people have 64-bit processors, so no one writes software for them. But since there's no software, no one has a reason to get a 64-bit processor!

But... Linux already runs in 64-bit mode on AMD64 (Opteron, Athlon64) processors (and soon FreeBSD and NetBSD will, too). So people running Linux on an AMD64 just have to recompile mencoder and instantly get a 64-bit video encoder (it might not take full advantage of the larger data path, but should still be faster than a 32-bit-compiled version).

kwag · #11 01-06-2004, 05:22 PM

NetBSD was the world's first OS to run on a 64 bit platform. The Alpha.
http://www.netbsd.org/Ports/alpha/
Linux came way later.
FreeBSD also runs on Alpha and is currently being tested on IA-64 and AMD64.

-kwag

BobNET · #12 01-06-2004, 07:19 PM

Don't forget about the UltraSparcII... we had a whole lab of 300MHz Ultra 5 workstations put in in 1999 and they blew away all the other systems at the school (except possibly the 450MHz P3s from IBM, which were mainly used to play Quake 3

)

But AMD64 and PowerPC G5 processors are the first 64-bit systems readily available and cheap enough for home users...

Alpha systems were cool, though (still would be, but I think they stopped production on them). I remember reading about them in high school and thinking "1GHz processors! I'll never have one that fast!"

They're still the best for numeric computations (although the Itanium processors are supposed to be as good or better, I haven't had the chance to use one though)...

kwag · #13 01-06-2004, 09:33 PM

Yeah, the UltraSparcII and the Alphas are really cheap now at E-Bay

I bought a couple of "Multias" a couple of years ago, and I installed NetBSD on them. They were SLOWWWW and hot

But the worked fine as a small ftp and web server.
NetBSD should run really great on the Sparcs. I've been told that NetBSD on Sparc runs circles around Linux (on the same machine)

As a matter of fact, NetBSD and FreeBSD (not Linux!) are being used here: http://ctd.lerc.nasa.gov/5610/tcpextensions.html extensively

-kwag

BobNET · #14 01-06-2004, 11:29 PM

Quote:

Originally Posted by Kwag

NetBSD should run really great on the Sparcs. I've been told that NetBSD on Sparc runs circles around Linux (on the same machine)

I somehow ended up with a SparcStation 5 (170MHz TurboSparc processor, unfortunately only 32-bit). It runs OpenBSD and is used mainly as a router/firewall... never tried Linux on it since BSD worked right from the start.

Quote:

As a matter of fact, NetBSD and FreeBSD (not Linux!) are being used here: http://ctd.lerc.nasa.gov/5610/tcpextensions.html extensively

Talking to satellites with TCP... reminds me of this comment from the Linux kernel (net/ipv4/tcp_timer.c):

Code:

        /* Increase the timeout each time we retransmit.  Note that
         * we do not increase the rtt estimate.  rto is initialized
         * from rtt, but increases here.  Jacobson (SIGCOMM 88) suggests
         * that doubling rto each time is the least we can get away with.
         * In KA9Q, Karn uses this for the first few times, and then
         * goes to quadratic.  netBSD doubles, but only goes up to *64,
         * and clamps at 1 to 64 sec afterwards.  Note that 120 sec is
         * defined in the protocol as the maximum possible RTT.  I guess
         * we'll have to use something other than TCP to talk to the
         * University of Mars.
         *
         * PAWS allows us longer timeouts and large windows, so once
         * implemented ftp to mars will work nicely. We will have to fix
         * the 120 second clamps though!
         */

kwag · #15 01-06-2004, 11:50 PM

Quote:

Originally Posted by BobNET

Talking to satellites with TCP... reminds me of this comment from the Linux kernel (net/ipv4/tcp_timer.c):

Code:

        /* Increase the timeout each time we retransmit.  Note that
         * we do not increase the rtt estimate.  rto is initialized
         * from rtt, but increases here.  Jacobson (SIGCOMM 88) suggests
         * that doubling rto each time is the least we can get away with.
         * In KA9Q, Karn uses this for the first few times, and then
         * goes to quadratic.  netBSD doubles, but only goes up to *64,
         * and clamps at 1 to 64 sec afterwards.  Note that 120 sec is
         * defined in the protocol as the maximum possible RTT.  I guess
         * we'll have to use something other than TCP to talk to the
         * University of Mars.
         *
         * PAWS allows us longer timeouts and large windows, so once
         * implemented ftp to mars will work nicely. We will have to fix
         * the 120 second clamps though!
         */

That's good. Really good

KA9Q, yeah, reminds me of my early days when I got my Extra Class Amateur license, and I did a lot of experimenting via HF bands with his program. I also used Mike Pechura's (WA8BXN) MSYS program, which was my first FTP experience via amateur radio, at 300 baud

Fun days

73's DE KP4QG

-kwag