Hmm. Must've been very late 1999 (Quake3 was released nearly a year after I ditched my G200 in favor of a Riva TNT, which was probably around Jan-Feb '99.) I bought the G200 in August '98 because Matrox was promising all sorts of support, and all I know is by the time I stopped checking to see if anything had happened (4-5 months after purchasing the TNT), nothing significant had yet been delivered and the only 3D available on the Gx00 series was based on the earlier generation Mystique cards (and was EXTREMELY limited - no texture mapping for example.)
The last big news I saw was not that they OSed the drivers, but that they had given partial card specs and promised more.
Please note that Matrox did the same thing in 1999 - They gave partial card specs (insufficient for implementing any 3D) and promised more, but never delivered. Lots of Linux users got suckered into buying paperweight G200s (including myself) back then. I will buy a card that performs as advertised NOW (whether or not it is with an open source driver or not), not a card that the manufacturer promises will eventually perform as advertised but can't at the moment.
I agree. I fully support anything that does QoS and packet prioritization (by protocol, NOT by source/destination - I even do it on my own personal network to improve usability so I can leave BT running while I play games), but what Comcast is doing is NOT that.
QoS means that stuff like BitTorrent is last priority during heavy usage periods compared to more latency-sensitive protocols. Fine.
The problem is that Comcast is actively *killing* connections that meet certain criteria (not just BitTorrent - Sending attachments larger than 500k-1M in Lotus Notes is also broken) rather than slowing them down or altering their priority. They are doing this regardless of what other network load conditions may exist. i.e. they interfere with users' upstream connections regardless of time of day, whether or not it's 6 PM when the network is at peak usage, or 3 AM when a few people using BT is the only load present on the network.
"if the CPU is the bottleneck, how could adding more threads possibly help?"
Pretty sure the article summary covered this - it is intended for multicore/multiprocessor systems.
i.e. a single CPU is a bottleneck, but multithreading allows the load to be distributed over multiple CPUs, removing the bottleneck a single CPU might provide.
Older implementations of TCP only allow for a 64 KB window size. (Older meaning "really old" - nearly any implementation in the last decade implements extensions that allow for much larger transmit/receive windows.)
Many apps set fixed window sizes (incl. apparently standard SSH - the webpage implies 64K.)
Linux can "autotune" window sizes, but most OSes don't, hence the need for an app to be able to specify a larger window.
Even with larger window sizes, TCP congestion control starts breaking on networks with high speed and large BDP. For example, even with a BER of something like 1*10^-12, a gigabit connection will drop something like one packet per hour - on a gigabit connection with 400 ms latency, 1 hour is apparently about how long it will take for the congestion control algorithm to even ramp up to full wire speed. One packet drop and all of a sudden TCP throttles way back - hence the large amount of work on advanced congestion control algorithms that handle high BDP networks better. (Such as the current default algo in Linux, CUBIC.)
Using multiple TCP streams works around this problem in a more cross-platform manner as it does not depend on the OS's TCP implementation getting tweaked.
The news isn't that one or two cables got cut (which would not have too much impact on service to a given region), it's that multiple cables in a single region have gone down in the span of only one week, resulting in significant service degradation to a region of the world.
Same here. Both Game Boys I've owned in the past failed within 2-3 years in this manner (vertical columns of the display failing). Attempts to clean and reseat the connector never helped and usually made the problem worse.
Actually, that's more likely you simply saturating your upstream without any QoS. If ACKs for downstream data can't get out in a timely fashion, downstream TCP sessions (web pages) will slow to a crawl. Cable modems are notorious for having very large buffers, so that if the upstream bandwidth gets saturated, latency shoots through the roof.
Either: 1) Set up QoS on your router so outgoing ACKs always have priority, and possibly BT has lower priority than all other traffic (Note, this is what Comcast SHOULD be doing, instead of their current RST injection scheme.) 2) Set your BT client to cap outgoing bandwidth to 80% or so of your upstream cap. Use one of the speedtest websites to find out what this cap is
Also, the way in which it is done makes a big difference.
If Comcast were dropping the priority of packets suspected to be BitTorrent so that BT sessions slowed down during peak periods in favor of more "interactive" traffic, it wouldn't be so bad.
The problem is that they're not really throttling - they are actively killing connections by injecting bogus RST packets, regardless of time of day. (Despite their claims that traffic is only "delayed" at "peak times", which would be understandable and fine with me.) Unfortunately, while BT recovers somewhat from such active RST injection (it just starts up again), it completely breaks other protocols (such as sending email to a Lotus Notes server.)
That's false. There are numerous (Wireshark-confirmed) reports of RST injection happening on ANY TCP stream with a signficant amount of upstream bandwidth for more than a very short period of time.
For example, there's a well documented incident where Comcast's RST injection is killing Lotus Notes sessions where moderate sized (>1MB) attachments are sent.
To anyone who might reply, "Just uninstall it" - Easier said than done.
In my opinon, most Symantec products are more difficult to clean from a system than the malware they're supposed to protect against. The only way to get rid of it is to nuke and repave Windows.
"And if analog video support is removed then why does the S-Video port (analog) on my nVidia card still work?"
He means VGA when he says analog. And it's supported, but "crippled" so that with many forms of media, performs only somewhat better (540p) than that S-Video port, or is completely disabled.
Your S-Video port isn't crippled below its full capabilities because in the MAFIAA's eyes, it's already sufficiently crippled to begin with. (Limited to 480i output.)
They probably are pulling a Matrox. Release partial specs, promise to release more, rake in $$$$$$$$$$ from gullible members of the Open Source community, fail to deliver on promises. Great short-term strategy but only works once before said community stops trusting you, especially those who were dumb enough to go for your promises like I was back in 1999.
Ever since I made the mistake of buying a Matrox G200 (Partial specs - more complete than what ATI has released so far as I understand it, and a promise for full specs which were never delivered) I never make buying decisions based on promised specification/driver releases - only what works NOW, whether binary or not. (Hence I've been happily buying NVidia for 6-7 years now.)
There is another patch that adds high resolution timers to Linux. (Actually, another component of a gigantic patchset that has been rapidly getting mainlined over the past few kernel releases.)
I think CONFIG_HRTIMERS is already an option (may not default to on though). If it isn't, go find the RT_PREEMPT patchset. That includes (or if HRTIMERS is in the kernel, included) HRTIMERS, it's also where the NO_HZ option came from.
Windows power management used to SUCK in early versions of XP. XP's support for SpeedStep on Pentium 4-M CPUs was abysmal, for example. The Windows 2000 SpeedStep app from Intel (which didn't work in XP) was lightyears ahead of what XP had built in. Back in 2001-2002, Linux could easily blow away a Windows machine in terms of power consumption. Since then XP has improved due to lots and lots of "behind the scenes" tweaks, and to some degree, hardware manufacturer cooperation.
For example, one of the few things the Linux NVidia drivers still don't support well is power management. (ATI isn't any better in this regard though.)
The music industry completely screwed up with allofmp3 - It's a classic example of a dying industry trying to hold on with legislation instead of competing.
Rather than complain and moan about it, the RIAA should've figured out why allofmp3 was doing so well. It wasn't just the prices.
1) Selection as good as, or in many cases even better than many existing stores. About the only online store that does better is ITMS in my opinion. 2) NO DRM. Makes selection variety a bit less important, as there's less incentive to stick with a single store. (In some ways bad for a store if it's easier to go to someone else, but if your selection stinks and/or is niche, you're going to find that no one chooses you if you've got DRM.) 3) Not overpriced. Admittedly too cheap, but the RIAA could've made a store at twice the prices and still have been wildly successful. (Why? Legality = convenience, as far as "ease of payment", and twice Allofmp3's prices would have still been far below current RIAA-sanctioned stores.)
The RIAA wants to hang on to high per-track prices, but they should be thinking about sacrificing per-track profits to drastically increase volume. For example, if someone hears a track they really like on the radio or elsewhere, they're likely to buy the entire album at $3. But at $10+ for the entire album, they'll probably just buy only that track at $1, given the tendency for albums to have a lot of "filler crap".
"Regardless, if we don't want this then the states need to be firm in their opposition to it." Some states are not going to bother opposing this at all.
The reason? It doesn't affect them in the slightest.
Why? Because they already implement all of the requirements the law will impose.
For example, apparently the only difference for California will be that the drivers' picture will be taken at the beginning of the license application process instead of at the end.
For NYS residents like myself, it will apparently change minimally if at all.
"But what is the benefit? Remember that the 9/11 hijackers all had valid IDs -- identification would not have prevented that tragedy."
Improvements to the process of obtaining such identification might have.
They may have been valid as in "not counterfeit" but were most certainly invalid in terms of "obtained in a proper manner" - it is not possible for someone to have a drivers' license from multiple states simultaneously, as you are required to surrender your out-of-state license when obtaining one in another state.
(Disclaimer: This is the case in NY, but might not be the case in other states. The new rules standardize such aspects of the process.)
"Hehe, does New Jersey still do that? We loved New Jersey IDs back in the day before any of us were 21......" Nope, NJ overhauled their license significantly 4-5 years ago. I'm surprised it's not on the "compliant or near compliant" list in the article, as I recall my latest NJ license before moving to NY in January 2006 was both fancier and required more proof of identity to obtain than my current NY license.
"I don't recall reading that any of the 9/11 hijackers used fake IDs to get onto the airplanes. They obtained them quite legally. Perhaps we should be looking into reforming who can obtain a drivers license, rather then reforming the drivers license itself."
Based on reading the article, it looks like most of the changes being made are not changes to the license itself, but to the process of obtaining them.
It appears to me that this is not a "federal ID", but consists of the following: 1) Requirements levied on the process of granting a person a drivers' license, in terms of verifying that that person is who they say they are. 2) Requirements levied on the anti-counterfeiting features of that license.
TFA states that a number of states already issue licenses that meet all of these requirements. For example, California residents will apparently not notice any difference except the point at which their picture is taken during the process of obtaining a license. From the looks of it, this will also not affect me, as my state (New York) already implements all of the process and anti-counterfeiting requirements levied here.
Too slow. TOSLINK uses VERY thick POF, and the modal dispersion limits it to very short runs and/or very low speeds (a few megabits/sec over tens of meters).
"A better question is why are people associating brightness (loss) with speed?"
Probably thinking about RF channels, where SNR is a major factor in speed. With most fiber runs, it is not. Except for long-haul multi-kilometer runs, SNR is always pretty high.
The problem is optical and modal dispersion.
Optical dispersion is the same phenomenon as a prism - light travels different speeds depending on frequency. This causes pulses to spread. The higher the speed, the larger difference between min/max frequency of the light, the more spreading that occurs. Over singlemode fiber, optical dispersion is usually the limiting factor on speed, unless compensated for. (There are ways to do so.)
Modal dispersion is best described as the light having multiple paths it can take from one end of the fiber to another. These paths are not of equal length, so it makes pulses spread out too. Modal dispersion usually dominates optical dispersion, except in single-mode (very narrow, very hard to work with) fiber. Thick plastic fibers will have significantly worse modal dispersion than even multimode glass, imposing a pretty nasty length*speed limit on the fiber. Fortunately, for this application, length is short allowing for usable speeds.
That said - Some of the 100M Ethernet standards already use visible light and LED emitters, so this new effort isn't a gigantic leap.
They unfortunately are focusing (apparently) on internal building wiring, where fiber (esp. plastic multimode) loses many of its advantages over copper. "last mile" outdoor cabling provides far more advantages to fiber (Lack of EMI susceptibility, corrosion resistance, etc.)
Routing through point A to point B in a directed graph is a solved problem - Dijkstra's algorithm isn't that bad computationally, and there are others that have the same worst-case performance as Dijkstra but better average performance (such as I believe A*).
What your GPS supports is just applying the same problem sequentially. Given points A,B,C,D,..., visit them in the user-specified order. A to B, B to C,...
What the article poster wants is:
Given starting point A, what is the best way to visit points B,C,D,E,... - Order does not matter other than starting and ending at A.
Slashdot Mirror
Hmm. Must've been very late 1999 (Quake3 was released nearly a year after I ditched my G200 in favor of a Riva TNT, which was probably around Jan-Feb '99.) I bought the G200 in August '98 because Matrox was promising all sorts of support, and all I know is by the time I stopped checking to see if anything had happened (4-5 months after purchasing the TNT), nothing significant had yet been delivered and the only 3D available on the Gx00 series was based on the earlier generation Mystique cards (and was EXTREMELY limited - no texture mapping for example.)
"ATI needs the market share too badly."
So did Matrox...
Have they? Where's the big news announcement?
The last big news I saw was not that they OSed the drivers, but that they had given partial card specs and promised more.
Please note that Matrox did the same thing in 1999 - They gave partial card specs (insufficient for implementing any 3D) and promised more, but never delivered. Lots of Linux users got suckered into buying paperweight G200s (including myself) back then. I will buy a card that performs as advertised NOW (whether or not it is with an open source driver or not), not a card that the manufacturer promises will eventually perform as advertised but can't at the moment.
I agree. I fully support anything that does QoS and packet prioritization (by protocol, NOT by source/destination - I even do it on my own personal network to improve usability so I can leave BT running while I play games), but what Comcast is doing is NOT that.
QoS means that stuff like BitTorrent is last priority during heavy usage periods compared to more latency-sensitive protocols. Fine.
The problem is that Comcast is actively *killing* connections that meet certain criteria (not just BitTorrent - Sending attachments larger than 500k-1M in Lotus Notes is also broken) rather than slowing them down or altering their priority. They are doing this regardless of what other network load conditions may exist. i.e. they interfere with users' upstream connections regardless of time of day, whether or not it's 6 PM when the network is at peak usage, or 3 AM when a few people using BT is the only load present on the network.
"if the CPU is the bottleneck, how could adding more threads possibly help?"
Pretty sure the article summary covered this - it is intended for multicore/multiprocessor systems.
i.e. a single CPU is a bottleneck, but multithreading allows the load to be distributed over multiple CPUs, removing the bottleneck a single CPU might provide.
Older implementations of TCP only allow for a 64 KB window size. (Older meaning "really old" - nearly any implementation in the last decade implements extensions that allow for much larger transmit/receive windows.)
Many apps set fixed window sizes (incl. apparently standard SSH - the webpage implies 64K.)
Linux can "autotune" window sizes, but most OSes don't, hence the need for an app to be able to specify a larger window.
Even with larger window sizes, TCP congestion control starts breaking on networks with high speed and large BDP. For example, even with a BER of something like 1*10^-12, a gigabit connection will drop something like one packet per hour - on a gigabit connection with 400 ms latency, 1 hour is apparently about how long it will take for the congestion control algorithm to even ramp up to full wire speed. One packet drop and all of a sudden TCP throttles way back - hence the large amount of work on advanced congestion control algorithms that handle high BDP networks better. (Such as the current default algo in Linux, CUBIC.)
Using multiple TCP streams works around this problem in a more cross-platform manner as it does not depend on the OS's TCP implementation getting tweaked.
The news isn't that one or two cables got cut (which would not have too much impact on service to a given region), it's that multiple cables in a single region have gone down in the span of only one week, resulting in significant service degradation to a region of the world.
Same here. Both Game Boys I've owned in the past failed within 2-3 years in this manner (vertical columns of the display failing). Attempts to clean and reseat the connector never helped and usually made the problem worse.
Actually, that's more likely you simply saturating your upstream without any QoS. If ACKs for downstream data can't get out in a timely fashion, downstream TCP sessions (web pages) will slow to a crawl. Cable modems are notorious for having very large buffers, so that if the upstream bandwidth gets saturated, latency shoots through the roof.
Either:
1) Set up QoS on your router so outgoing ACKs always have priority, and possibly BT has lower priority than all other traffic (Note, this is what Comcast SHOULD be doing, instead of their current RST injection scheme.)
2) Set your BT client to cap outgoing bandwidth to 80% or so of your upstream cap. Use one of the speedtest websites to find out what this cap is
Also, the way in which it is done makes a big difference.
If Comcast were dropping the priority of packets suspected to be BitTorrent so that BT sessions slowed down during peak periods in favor of more "interactive" traffic, it wouldn't be so bad.
The problem is that they're not really throttling - they are actively killing connections by injecting bogus RST packets, regardless of time of day. (Despite their claims that traffic is only "delayed" at "peak times", which would be understandable and fine with me.) Unfortunately, while BT recovers somewhat from such active RST injection (it just starts up again), it completely breaks other protocols (such as sending email to a Lotus Notes server.)
That's false. There are numerous (Wireshark-confirmed) reports of RST injection happening on ANY TCP stream with a signficant amount of upstream bandwidth for more than a very short period of time.
For example, there's a well documented incident where Comcast's RST injection is killing Lotus Notes sessions where moderate sized (>1MB) attachments are sent.
To anyone who might reply, "Just uninstall it" - Easier said than done.
In my opinon, most Symantec products are more difficult to clean from a system than the malware they're supposed to protect against. The only way to get rid of it is to nuke and repave Windows.
"And if analog video support is removed then why does the S-Video port (analog) on my nVidia card still work?"
He means VGA when he says analog. And it's supported, but "crippled" so that with many forms of media, performs only somewhat better (540p) than that S-Video port, or is completely disabled.
Your S-Video port isn't crippled below its full capabilities because in the MAFIAA's eyes, it's already sufficiently crippled to begin with. (Limited to 480i output.)
They probably are pulling a Matrox. Release partial specs, promise to release more, rake in $$$$$$$$$$ from gullible members of the Open Source community, fail to deliver on promises. Great short-term strategy but only works once before said community stops trusting you, especially those who were dumb enough to go for your promises like I was back in 1999.
Ever since I made the mistake of buying a Matrox G200 (Partial specs - more complete than what ATI has released so far as I understand it, and a promise for full specs which were never delivered) I never make buying decisions based on promised specification/driver releases - only what works NOW, whether binary or not. (Hence I've been happily buying NVidia for 6-7 years now.)
There is another patch that adds high resolution timers to Linux. (Actually, another component of a gigantic patchset that has been rapidly getting mainlined over the past few kernel releases.)
I think CONFIG_HRTIMERS is already an option (may not default to on though). If it isn't, go find the RT_PREEMPT patchset. That includes (or if HRTIMERS is in the kernel, included) HRTIMERS, it's also where the NO_HZ option came from.
Windows power management used to SUCK in early versions of XP. XP's support for SpeedStep on Pentium 4-M CPUs was abysmal, for example. The Windows 2000 SpeedStep app from Intel (which didn't work in XP) was lightyears ahead of what XP had built in. Back in 2001-2002, Linux could easily blow away a Windows machine in terms of power consumption. Since then XP has improved due to lots and lots of "behind the scenes" tweaks, and to some degree, hardware manufacturer cooperation.
For example, one of the few things the Linux NVidia drivers still don't support well is power management. (ATI isn't any better in this regard though.)
The music industry completely screwed up with allofmp3 - It's a classic example of a dying industry trying to hold on with legislation instead of competing.
Rather than complain and moan about it, the RIAA should've figured out why allofmp3 was doing so well. It wasn't just the prices.
1) Selection as good as, or in many cases even better than many existing stores. About the only online store that does better is ITMS in my opinion.
2) NO DRM. Makes selection variety a bit less important, as there's less incentive to stick with a single store. (In some ways bad for a store if it's easier to go to someone else, but if your selection stinks and/or is niche, you're going to find that no one chooses you if you've got DRM.)
3) Not overpriced. Admittedly too cheap, but the RIAA could've made a store at twice the prices and still have been wildly successful. (Why? Legality = convenience, as far as "ease of payment", and twice Allofmp3's prices would have still been far below current RIAA-sanctioned stores.)
The RIAA wants to hang on to high per-track prices, but they should be thinking about sacrificing per-track profits to drastically increase volume. For example, if someone hears a track they really like on the radio or elsewhere, they're likely to buy the entire album at $3. But at $10+ for the entire album, they'll probably just buy only that track at $1, given the tendency for albums to have a lot of "filler crap".
"Regardless, if we don't want this then the states need to be firm in their opposition to it."
Some states are not going to bother opposing this at all.
The reason? It doesn't affect them in the slightest.
Why? Because they already implement all of the requirements the law will impose.
For example, apparently the only difference for California will be that the drivers' picture will be taken at the beginning of the license application process instead of at the end.
For NYS residents like myself, it will apparently change minimally if at all.
"But what is the benefit? Remember that the 9/11 hijackers all had valid IDs -- identification would not have prevented that tragedy."
Improvements to the process of obtaining such identification might have.
They may have been valid as in "not counterfeit" but were most certainly invalid in terms of "obtained in a proper manner" - it is not possible for someone to have a drivers' license from multiple states simultaneously, as you are required to surrender your out-of-state license when obtaining one in another state.
(Disclaimer: This is the case in NY, but might not be the case in other states. The new rules standardize such aspects of the process.)
"Hehe, does New Jersey still do that? We loved New Jersey IDs back in the day before any of us were 21......"
Nope, NJ overhauled their license significantly 4-5 years ago. I'm surprised it's not on the "compliant or near compliant" list in the article, as I recall my latest NJ license before moving to NY in January 2006 was both fancier and required more proof of identity to obtain than my current NY license.
"I don't recall reading that any of the 9/11 hijackers used fake IDs to get onto the airplanes. They obtained them quite legally. Perhaps we should be looking into reforming who can obtain a drivers license, rather then reforming the drivers license itself."
Based on reading the article, it looks like most of the changes being made are not changes to the license itself, but to the process of obtaining them.
It appears to me that this is not a "federal ID", but consists of the following:
1) Requirements levied on the process of granting a person a drivers' license, in terms of verifying that that person is who they say they are.
2) Requirements levied on the anti-counterfeiting features of that license.
TFA states that a number of states already issue licenses that meet all of these requirements. For example, California residents will apparently not notice any difference except the point at which their picture is taken during the process of obtaining a license. From the looks of it, this will also not affect me, as my state (New York) already implements all of the process and anti-counterfeiting requirements levied here.
Too slow. TOSLINK uses VERY thick POF, and the modal dispersion limits it to very short runs and/or very low speeds (a few megabits/sec over tens of meters).
"The only technical advantage plastic fiber has over CAT5/CAT6 is the eletrical isolation, which makes it more or less immune to lightning."
Corrosion resistance, too.
The article implies their goal is indoor wiring though. (But then talks about the last mile... which is it?)
The effort makes a LOT of sense for last-mile solutions.
It doesn't make nearly as much sense for indoors.
"A better question is why are people associating brightness (loss) with speed?"
Probably thinking about RF channels, where SNR is a major factor in speed. With most fiber runs, it is not. Except for long-haul multi-kilometer runs, SNR is always pretty high.
The problem is optical and modal dispersion.
Optical dispersion is the same phenomenon as a prism - light travels different speeds depending on frequency. This causes pulses to spread. The higher the speed, the larger difference between min/max frequency of the light, the more spreading that occurs. Over singlemode fiber, optical dispersion is usually the limiting factor on speed, unless compensated for. (There are ways to do so.)
Modal dispersion is best described as the light having multiple paths it can take from one end of the fiber to another. These paths are not of equal length, so it makes pulses spread out too. Modal dispersion usually dominates optical dispersion, except in single-mode (very narrow, very hard to work with) fiber. Thick plastic fibers will have significantly worse modal dispersion than even multimode glass, imposing a pretty nasty length*speed limit on the fiber. Fortunately, for this application, length is short allowing for usable speeds.
That said - Some of the 100M Ethernet standards already use visible light and LED emitters, so this new effort isn't a gigantic leap.
They unfortunately are focusing (apparently) on internal building wiring, where fiber (esp. plastic multimode) loses many of its advantages over copper. "last mile" outdoor cabling provides far more advantages to fiber (Lack of EMI susceptibility, corrosion resistance, etc.)
Different problem.
...
Routing through point A to point B in a directed graph is a solved problem - Dijkstra's algorithm isn't that bad computationally, and there are others that have the same worst-case performance as Dijkstra but better average performance (such as I believe A*).
What your GPS supports is just applying the same problem sequentially. Given points A,B,C,D,..., visit them in the user-specified order. A to B, B to C,
What the article poster wants is:
Given starting point A, what is the best way to visit points B,C,D,E,... - Order does not matter other than starting and ending at A.