Bones: "Damn it Jim! I'm a doctor not a [ bricklayer | magician | raving lunatic | chipindale dancer | trapeze artist | system administrator | kernel hacker | actor | latrine steward | sex maniac | CowboyNeal]"
(IMO, this is a much better way to wake up, than any damned radio alarm clock. I rigged this solution after a late coding session at work forced me to sleep under my desk. -_-)
The host should generate an ISN when it returns the Syn/Ack packet.
For each sequential packet, a new ISN is generated.
For every packet the server sends the client, the client MUST respond with an ACK message, with the appropriate ISN. If the server does not receive this ACK, it will assume that the packet is lost, and re-try a couple of times before giving up.
This is what gives TCP/IP it's connection based "guaranteed delivery" nature. Because of the ISN, it can detect lost packets, and can re-send them, allowing TCP/IP to work over connections with extreme loss (I'd say that it would still function with more than 95% loss, but, that is just a guess.)
Beyond guaranteeing delivery, the ISN also provides security.
Say that 4.1.1.1 is sending packets that are marked to have come from 100.2.2.2, to server 1.1.1.1.
During the 3 way handshake (Syn, Syn/Ack, Ack,) all packets from server 1.1.1.1 would be routed to the correct destination (100.2.2.2,) even though they were actually from 4.1.1.1.
Because 4.1.1.1 did not receive the Syn/Ack packets that the server (1.1.1.1) sent, it has absolutely no idea what ISN to respond with.
Since 100.2.2.2 did not initiate a connection to 1.1.1.1, all packets from the 1.1.1.1 will be ignored.
Now, let's say that 1.1.1.1 trusts 100.2.2.2 with a rsh root account, that does not require password authentication, when, and only when, 100.2.2.2 connects.
With good random ISN generation, 4.1.1.1 will not be able to create any kind of connection to 1.1.1.1.
Unfortunately, some operating systems, such as Windows, and Mac OS, generate terrible ISNs.
With windows, you have a 1 in 7 probability of guessing the correct ISN. With Mac OS, you have a 100% probability of guessing the correct number (unless you are a fucking idiot.;-)
Even with the correct ISN, 4.1.1.1 will not be able to see any response to it's actions, HOWEVER, it could make enough correct guesses to log in as root, and install a root Trojan, allowing it to create a genuine connection to the server, under it's own IP address, resulting in a compromised box, and a !3e+ 5|<41|>7 k1<!dy with a big pudgy.
I've also heard of loop back attacks, against a server. Utilizing Windows NT's weak ISN generation, and a couple of server daemons, there have been cases where people have managed to get 2 Windows NT services to initiate a connection to each other. As one generates errors, the other responds with errors of it's own, resulting in a feedback loop that eventually takes the server offline.
Please note that I'm not a TCP/IP engineer. Feel free to correct any errors in this explanation.
Okay, this is going to end up another "Why is that post moderated up" but I do have a point:
Remember that not everyone knows how to spell Altavista. If someone told you Alt*ae*vis*ta on the street, you may end up trying any number of erroneous domain names... Perhaps actavista, Aliavista, autavista, or even antavista?:-)
Look at MY URL: http://www.nodachi.net. When I tell someone "Nodachi", they most likely end up spelling it "Nodatchi", "Nodotchi" or "Nodotchee."
(Hell, word spells it "Nod", "Noachian", and "Joachim"...)
Well, for one thing movies use a technique known as blurring to mask lower framerates. To employ this on a gaming machine, you will most likely be forced to render the same frame a number of times (such as with 3DFX's T-Buffer) and then meld them together, or use some form of morphing algorithm (which will most likely slow things down further.)
Obviously neither of those are good answers for slower computers: In order to mask a slow framerate useing these techniques, you will be forced to do 4X the work, resulting in a very poor gaming experience. (Wow! 1.75FPS AND blurry!)
As for your system, if you haven't done so already, reduce your resolution and detail settings. At 7FPS you are asking far to much of your computer.
Barring that, Voodoo3s and Pentium III 500s are cheap now. Consider upgrading.
...but it seems to me that until we can render 75FPS at 1600x1200 in the latest games, using the most demanding rendering options we will never have an overly powerful system.
Who here runs games at anything less than 1024x760? What about full screen Anti Aliasing?
I can guarantee that quake3 will crush even the most powerful machines if you try to play at 1600x1200x32 bit color, with highly detailed textures, etc. etc.
Even more so, with FSAA most games are only playable at a maximum resolution of 1024x760 on most modern video cards.
Even then all of this is assumes that games are NOT getting more complex.
Listen, I'll consider the point when I can get Pixar quality gaming at a resolution of 2048x1536x32, with FSAA and still break that 75FPS limit, and not a minute before.
I must ask myself: Are you here to waste my time? Are you pissed because you are unable to argue my logic (which would be sad indeed,) and instead choose to post pointless remarks?
It's easy to read a few benchmarks, and fall under the impression that one thing is superior to another.
Remember that people will generally believe something because they want to, without questioning their own biases - this is true for everyone, PPC and x86 users alike.
Now, to answer your question about x86 processors: exactly why should we move away from x86?
Performance? Check this out: The 1.0GHz Thunderbirds are faster than Sun's Ultra 10 Sparc IIi 440 based systems in SPEC FP95.
Certainly the Athlon isn't as reliable, and doesn't have such an elegant memory subsystem, but for home and work?
Here's the deal: the x86 architecture does what we need it to do - that's what counts. We can play games, run office, and surf the net. Furthermore we already have (literally) millions of working applications that would need to be ported... All for what? A more elegant architecture?
Take a look at the Itanium - VLIW, and a gigantic waste of time and money. How many people here will be running one when it is finally released? It'll be 5 years before the thing makes it down to the workstation market...
When it does will Intel be asking themselves if is was worth it? Will Slashdot be asking if it's a good idea to move to Intel's monopolized platform?
Even worse is the arguments being used here... Have you ever heard people tell you why RISC is better? Usually the argument is a higher IPC (Instructions Per Clock IIRC.)
RISC, or Reduced Instruction Set Computing - the ideal being to simplify the processor to improve clock speeds, and reduce power consumption... Transmeta or ARM anyone?
The PowerPC is very un-RISC like in that regard. More instructions, more power. Throw more stuff on the core to improve the IPC, at the cost of reduced clock speeds.
Regardless, ask yourself weather it is really necessary to move away from x86, or weather someone is simply biased against your architecture for some un-vocalized reason.
If you really want to find out, talk to the person who codes in assembler, or programs emulators rather than taking the word of a guy who purchased a fruit.
http://www.mackido.com is a good start. The information comes from a somewhat biased source IMO, however, he also does some serious development.
IPv6 (Or IPNG, whichever you prefer) does not support any kind of backwards compatibility natively...
To answer this technical difficulty, people have the option of using IPv4 tunneling over IPv6, or IPv6 tunneling over IPv4.
IPv6 over IPv4 allows for IPv6 machines to engage in IPv6 networks on non IPv6 ISPs, and IPv4 over IPv6 could be used to link legacy machines over IPNG networks.
Furthermore, nothing says a person cannot use a dual stack system - this would be very similar to running IPX or NetBEUI (Wah!) on a machine that runs IPv4 - I could be 3ffe:b00:c18:1fff:0:0:0:287 and still have 205.179.127.117.
One other thing about IPv6: It does not use subnet masks. Like the good old days of the net, the route to any host can be identified by the IP of the machine in question.
The IPv6 global aggregation addressing architecture splits addresses into two parts. The high-order 64 bits identify the network, and the low-order 64 bits identify the node. A format prefix gives the type of IPv6 address. Next comes a top-level aggregation entity, likely to be a country or a large carrier, followed by 8 bits reserved for future growth. Then comes another aggregation entity, likely to be a large company or Internet provider, and finally a site-level aggregation entity, probably assigned by the entity above it. Such addresses are far more efficient to route across backbones.
Aggregation means any address contains its own route. The first few bits of the address might indicate, say, Europe. The packet would go to a router serving Europe, which might see Portugal in the next few bits and forward the packet to Portugal's router. From there, the packet might go on to a router in Lisbon and then on to its final destination.
Figure 2 shows that the Top-Level Aggregation ID (TLA) uses 13 bits. This gives an upper limit of no more than 8,192 (2 to the 13th power) top-level entities, which pares down the size of the routing table a backbone router would have to deal with to forward packets anywhere in an IPv6 Internet. The next 8 bits are reserved, presumably held back, just in case the TLA allocation should be bigger (or the Next-Level Aggregation ID allocation should be bigger).
NLA entities are expected to include large ISPs, among others. These entities get their address allocations from the TLAs, who also handle routing for the NLAs. Each TLA can allocate as many as 16 million or so NLA networks (2 to the 24th) The NLAs, in turn, can allocate as many as 65,536 networks each (2 to the 16th) to Site-Level Aggregation (SLA) entities. In other words, network sites. And each SLA entity still has 64 bits of address space to play around with, for as many as 18 million trillion (18,446,744,073,709,551,616) nodes per network.
Obviously, using this scheme we will probably waste a lot of IP addresses, but there should be more than enough networks to relieve our IPv4 induced shortages.
One other item of interest is that your SLA entry should now be based on your hardware ethernet address. This may make large networks easier to manage without DHCP.
If you are interested in IPv6, I highly recommend you read the full article, linked from here. (The next version of the Internet protocol -- IPv6)
As for my opinion of this: the sooner the better. I'm loving the security measures Ipv6 will implement. Finally I'll be able to deal with 31337 k1dd13z who thinks ICMP floods are fun.
True. Of course, it's possible to build a 1000 processor Athlon system using current Beowulf clusters as well - however, this is a long shot from having them all on the same front side bus...
I don't know much about Cray's implementation of a 1000 CPU configuration, but I get the feeling it's similar to running a fat pipe (say, 10GBPS ATM) between the systems, and then using a form of clustering like the above between a number of major processor arrays.
Regardless, the latencies involved would force engineers to design with separate physical memory pools, instruction caches, etc.
"AMD is clearly trying to overtake Intel's lead in the field of 'failing to deliver'."
How so? AMD has delivered on every promise they've set since the original Athlon was launched last year...Thunderbirds, Durons... You name it.
I don't see this changing for the Mustang, or 760MP. They are in the lead, and the reputation they earned during the K6 days for an inability to deliver is now a fading memory. I doubt they are stupid enough to ruin this on a non main stream market chipset.
You are correct in regards to the processor's support for SMP. The current crop of Athlons (including the Athlon classic) are SMP capable.
In fact, they are SMP limited by the chipsets: If a chipset existed, you could run a box with 1000 Athlon processors - of course, designing such a beast would be impossible...
At any rate, Ace's Hardware has been covering AMD's products fairly diligently. They've posted several articles about the 760MP (The SMP capable Athlon chipset.) One good example is available here: http://www.aceshardware.com/Spades/read_news.php?p ost_id=10000214
From what I understand, the 760MP should be finished between December and January, and on store shelves late Q1 2000.
I mean, at least then things will be honest, rather than moderateing people +1, Insightful up for:
"Ace's Hardware has been covering AMD's advances fairly well - they have an SMP Capable chipset (the 760MP) in the works, which should be out by december.";-)
Ace's Hardware has been covering AMD's advances fairly well - they have an SMP Capable chipset (the 760MP) in the works, which should be out by december.
Slashdot Mirror
Bones: "Damn it Jim! I'm a doctor not a [ bricklayer | magician | raving lunatic | chipindale dancer | trapeze artist | system administrator | kernel hacker | actor | latrine steward | sex maniac | CowboyNeal ]"
I had already posted when I thought of that. -_-
/usr/local/bin/mpg123 ~/mp3s/Tool-Aenima/*.mp3
Um... Real geeks know no weekend.
Yeah...
30 6 * * 1-5
30 6 * * *
Guarentieed to wake you up in the morning. =)
(IMO, this is a much better way to wake up, than any damned radio alarm clock. I rigged this solution after a late coding session at work forced me to sleep under my desk. -_-)
Thank you, very much.
As I mentioned, I'm not a TCP/IP enginner, rather, a teenager with a good hobby, and WAY too much time on his hands.
=)
A basic TCP/IP Connection is created in this manar:
;-)
Client > Server: "Syn"
Server > Client: "Ack/Syn"
Client > Server: "Ack"
The host should generate an ISN when it returns the Syn/Ack packet.
For each sequential packet, a new ISN is generated.
For every packet the server sends the client, the client MUST respond with an ACK message, with the appropriate ISN. If the server does not receive this ACK, it will assume that the packet is lost, and re-try a couple of times before giving up. This is what gives TCP/IP it's connection based "guaranteed delivery" nature. Because of the ISN, it can detect lost packets, and can re-send them, allowing TCP/IP to work over connections with extreme loss (I'd say that it would still function with more than 95% loss, but, that is just a guess.)
Beyond guaranteeing delivery, the ISN also provides security.
Say that 4.1.1.1 is sending packets that are marked to have come from 100.2.2.2, to server 1.1.1.1.
During the 3 way handshake (Syn, Syn/Ack, Ack,) all packets from server 1.1.1.1 would be routed to the correct destination (100.2.2.2,) even though they were actually from 4.1.1.1.
Because 4.1.1.1 did not receive the Syn/Ack packets that the server (1.1.1.1) sent, it has absolutely no idea what ISN to respond with.
Since 100.2.2.2 did not initiate a connection to 1.1.1.1, all packets from the 1.1.1.1 will be ignored.
Now, let's say that 1.1.1.1 trusts 100.2.2.2 with a rsh root account, that does not require password authentication, when, and only when, 100.2.2.2 connects.
With good random ISN generation, 4.1.1.1 will not be able to create any kind of connection to 1.1.1.1.
Unfortunately, some operating systems, such as Windows, and Mac OS, generate terrible ISNs.
With windows, you have a 1 in 7 probability of guessing the correct ISN. With Mac OS, you have a 100% probability of guessing the correct number (unless you are a fucking idiot.
Even with the correct ISN, 4.1.1.1 will not be able to see any response to it's actions, HOWEVER, it could make enough correct guesses to log in as root, and install a root Trojan, allowing it to create a genuine connection to the server, under it's own IP address, resulting in a compromised box, and a !3e+ 5|<41|>7 k1<!dy with a big pudgy.
I've also heard of loop back attacks, against a server. Utilizing Windows NT's weak ISN generation, and a couple of server daemons, there have been cases where people have managed to get 2 Windows NT services to initiate a connection to each other. As one generates errors, the other responds with errors of it's own, resulting in a feedback loop that eventually takes the server offline.
Please note that I'm not a TCP/IP engineer. Feel free to correct any errors in this explanation.
" iF I EVER MeEt You, cAn I TWIST YoUr TITS? "
Geeze... And people wonder that there are so few female geeks?
Pentium 4 systems had been recalled from store shelves due to issues such as excessive heat and inadequate performance
Great, now if only we could recall a few elected officials for excessive stupidity.
Well, let's find out...
;-)
Ralph Neder
11913 Gard Ave
Norwalk, CA 90650-7942
(562)863-0635
Do you Yahoo?
Right, but most WYSI(sn't)WYG editors also insert a generator meta tag;
<META NAME="GENERATOR" CONTENT="Mozilla/4.05 [en] (Win95; I) [Netscape]">
(That's from a page I did nearly 3 years ago in Netscape Communicator.)
No, they remembered it... Look at their source:
:-)
<head>
<title>Untitled Document</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>
Now my question: Does this not make things even worse?
Okay, this is going to end up another "Why is that post moderated up" but I do have a point:
:-)
Remember that not everyone knows how to spell Altavista. If someone told you Alt*ae*vis*ta on the street, you may end up trying any number of erroneous domain names... Perhaps actavista, Aliavista, autavista, or even antavista?
Look at MY URL: http://www.nodachi.net. When I tell someone "Nodachi", they most likely end up spelling it "Nodatchi", "Nodotchi" or "Nodotchee."
(Hell, word spells it "Nod", "Noachian", and "Joachim"...)
Otherwise, good point.
Well, for one thing movies use a technique known as blurring to mask lower framerates. To employ this on a gaming machine, you will most likely be forced to render the same frame a number of times (such as with 3DFX's T-Buffer) and then meld them together, or use some form of morphing algorithm (which will most likely slow things down further.)
Obviously neither of those are good answers for slower computers: In order to mask a slow framerate useing these techniques, you will be forced to do 4X the work, resulting in a very poor gaming experience. (Wow! 1.75FPS AND blurry!)
As for your system, if you haven't done so already, reduce your resolution and detail settings. At 7FPS you are asking far to much of your computer.
Barring that, Voodoo3s and Pentium III 500s are cheap now. Consider upgrading.
...but it seems to me that until we can render 75FPS at 1600x1200 in the latest games, using the most demanding rendering options we will never have an overly powerful system.
Who here runs games at anything less than 1024x760? What about full screen Anti Aliasing?
I can guarantee that quake3 will crush even the most powerful machines if you try to play at 1600x1200x32 bit color, with highly detailed textures, etc. etc.
Even more so, with FSAA most games are only playable at a maximum resolution of 1024x760 on most modern video cards.
Even then all of this is assumes that games are NOT getting more complex.
Listen, I'll consider the point when I can get Pixar quality gaming at a resolution of 2048x1536x32, with FSAA and still break that 75FPS limit, and not a minute before.
Wow! A lamer! I must have hit the big time!
WOHOO!
=)
Regardless, would you care to argue my points?
I must ask myself: Are you here to waste my time? Are you pissed because you are unable to argue my logic (which would be sad indeed,) and instead choose to post pointless remarks?
Perhaps it's just the grape...
Remember that "better" is a subjective term.
It's easy to read a few benchmarks, and fall under the impression that one thing is superior to another.
Remember that people will generally believe something because they want to, without questioning their own biases - this is true for everyone, PPC and x86 users alike.
Now, to answer your question about x86 processors: exactly why should we move away from x86?
Performance? Check this out: The 1.0GHz Thunderbirds are faster than Sun's Ultra 10 Sparc IIi 440 based systems in SPEC FP95.
Certainly the Athlon isn't as reliable, and doesn't have such an elegant memory subsystem, but for home and work?
Here's the deal: the x86 architecture does what we need it to do - that's what counts. We can play games, run office, and surf the net. Furthermore we already have (literally) millions of working applications that would need to be ported... All for what? A more elegant architecture?
Take a look at the Itanium - VLIW, and a gigantic waste of time and money. How many people here will be running one when it is finally released? It'll be 5 years before the thing makes it down to the workstation market...
When it does will Intel be asking themselves if is was worth it? Will Slashdot be asking if it's a good idea to move to Intel's monopolized platform?
Even worse is the arguments being used here... Have you ever heard people tell you why RISC is better? Usually the argument is a higher IPC (Instructions Per Clock IIRC.)
RISC, or Reduced Instruction Set Computing - the ideal being to simplify the processor to improve clock speeds, and reduce power consumption... Transmeta or ARM anyone?
The PowerPC is very un-RISC like in that regard. More instructions, more power. Throw more stuff on the core to improve the IPC, at the cost of reduced clock speeds.
Regardless, ask yourself weather it is really necessary to move away from x86, or weather someone is simply biased against your architecture for some un-vocalized reason.
If you really want to find out, talk to the person who codes in assembler, or programs emulators rather than taking the word of a guy who purchased a fruit.
http://www.mackido.com is a good start. The information comes from a somewhat biased source IMO, however, he also does some serious development.
For those of you who mistook his post for incoherent babbleing, pay attention: 54t4n here did in fact root every machine on the Internet.
Check those loopback interfaces boys! This 31337 d00d 0wn3z 127.0.0.1 *Grin*
(No, IANAL [I am not a looser])
To answer this technical difficulty, people have the option of using IPv4 tunneling over IPv6, or IPv6 tunneling over IPv4.
IPv6 over IPv4 allows for IPv6 machines to engage in IPv6 networks on non IPv6 ISPs, and IPv4 over IPv6 could be used to link legacy machines over IPNG networks.
Furthermore, nothing says a person cannot use a dual stack system - this would be very similar to running IPX or NetBEUI (Wah!) on a machine that runs IPv4 - I could be 3ffe:b00:c18:1fff:0:0:0:287 and still have 205.179.127.117.
One other thing about IPv6: It does not use subnet masks. Like the good old days of the net, the route to any host can be identified by the IP of the machine in question.
From Cross Nodes Obviously, using this scheme we will probably waste a lot of IP addresses, but there should be more than enough networks to relieve our IPv4 induced shortages.
One other item of interest is that your SLA entry should now be based on your hardware ethernet address. This may make large networks easier to manage without DHCP.
If you are interested in IPv6, I highly recommend you read the full article, linked from here. (The next version of the Internet protocol -- IPv6)
As for my opinion of this: the sooner the better. I'm loving the security measures Ipv6 will implement. Finally I'll be able to deal with 31337 k1dd13z who thinks ICMP floods are fun.
Soon it won't require months of work to morph yourself into a gargoyle ;)
Or, more likely; no more than 5 years to have the skin of dinosaurs. *G*
True. Of course, it's possible to build a 1000 processor Athlon system using current Beowulf clusters as well - however, this is a long shot from having them all on the same front side bus...
I don't know much about Cray's implementation of a 1000 CPU configuration, but I get the feeling it's similar to running a fat pipe (say, 10GBPS ATM) between the systems, and then using a form of clustering like the above between a number of major processor arrays.
Regardless, the latencies involved would force engineers to design with separate physical memory pools, instruction caches, etc.
Of course, I'm not a Cray engineer...
"AMD is clearly trying to overtake Intel's lead in the field of 'failing to deliver'."
How so? AMD has delivered on every promise they've set since the original Athlon was launched last year...Thunderbirds, Durons... You name it.
I don't see this changing for the Mustang, or 760MP. They are in the lead, and the reputation they earned during the K6 days for an inability to deliver is now a fading memory. I doubt they are stupid enough to ruin this on a non main stream market chipset.
By the way: AMD has no plans to cripple it's Duron processors.
p ost_id=15000265 - all Durons will be SMP capable, and, AFAIK, they should take full advantage of the 133MHz / PC266 DDR motherboards.
http://www.aceshardware.com/Spades/read_news.php?
You killed the first post kiddies! You bastard!
This has got to be the first time in recent slashdot history that a "post #1" has gotten any moderation other than down...
I think this deserves a toast, a slashdot story, and a redundent story, just to be sure!
You are correct in regards to the processor's support for SMP. The current crop of Athlons (including the Athlon classic) are SMP capable.
p ost_id=10000214
In fact, they are SMP limited by the chipsets: If a chipset existed, you could run a box with 1000 Athlon processors - of course, designing such a beast would be impossible...
At any rate, Ace's Hardware has been covering AMD's products fairly diligently. They've posted several articles about the 760MP (The SMP capable Athlon chipset.) One good example is available here: http://www.aceshardware.com/Spades/read_news.php?
From what I understand, the 760MP should be finished between December and January, and on store shelves late Q1 2000.
I wouldnt mind a +1, KarmaWhore...
;-)
I mean, at least then things will be honest, rather than moderateing people +1, Insightful up for:
"Ace's Hardware has been covering AMD's advances fairly well - they have an SMP Capable chipset (the 760MP) in the works, which should be out by december."
Ace's Hardware has been covering AMD's advances fairly well - they have an SMP Capable chipset (the 760MP) in the works, which should be out by december.
p ost_id=10000240
4 .html
A little bit of info here: http://www.aceshardware.com/Spades/read_news.php?
As for compaq: well, make what you wish of this: http://www.theregister.co.uk/content/archive/1222
I'd say that AMD is setting it's self up to replace Intel rather quickly. Already, many OEMs are droping their Intel only policy...