I normally don't reply to ACs, but what you're describing can only happen to a power supply that is OFF for extremely extended periods of time, with some other fan causing airflow into it.
Not gonna happen.
Each whisker that hits it will be vaporized long before your hundreds can build up.
Think about how thick a 3A fuse is, the fibers they're describing would have to pile in the THOUSANDS for this to happen, and all at once at that!
I would modify this statement to say that it is not common for someone to be...(c) not tied up with a company that insists on keeping the development work private.
Well, the poster did say that (s)he is a "former programmer", so (s)he doesn't appear to be under (her/)his company's thumb in (her/)his current position.
Then again, it does look like (s)he's trying to make a recommendation of software to evaluate to the company... so the company is already looking for software on the outside... so the below statement is negated anyways.
If you give away your code, others can use it to discover the same patterns; if enough people do that, the pattern will eventually be traded out of profitability.
I used to think that... until I had a long chat with a friend of mine who makes his living (even during/after the market crash!) doing nothing but trading stocks. I asked him why he posts his recommendations to an open public forum (thinking as you do that it would be bad). He said that the best thing that can happen is having everyone else buy when (well, immediately after) he does, as it creates a demand for the stock, which drives the price up quickly. The worst that can happen, is people ignore his post and nothing happens other than he gets a good deal (assuming he's "read" the market correctly).
Either way, (s)he needs to sell (her/)his company on the benefits of releasing Open Source software, which could provide considerable improvement to the software with minimal internal effort. Since this software is obviously not part of their core business (they're not a software producing company, they're looking to buy it), they would not be losing anything by releasing it under an Open Source license.
Yes, as I stated in my reply (to which you replied), I understand that the ehci would be needed for USB-2.0, and either ohci or uhci would be needed for USB-1.x.
My comment was about the fact that both ohci and uhci drivers were loaded. Those two are for different chip designs.
The most likely reason for a lack of free software for this application is it's not common for someone to have experience programming and this sort of thing.
You are in this unique position, so I would recommend you start such a project yourself.
The guy who posed the question said he's running RedHat 9, which is a 2.4 kernel based disto... not Mandrake running a 2.6 kernel.
If you're having the same issue, maybe it's because you're using 3 drivers at the same time.
If you have both USB-1.x and USB-2.0 ports on your box I can understand running ehci_hcd for the 2.0 card, but you only need one driver for the other interface. Frankly, I'm surprized it even loaded both 1.x drivers at the same time.
Forget running ethereal or other packet sniffers, they're far too fine-grained for what you're trying to do: prove they're being abused.
Connect a small box running your favorite *nix running ntop to the service port (or whatever they call it, I'm half asleep) of the switch/router to which the box(es) in question are connected.
That's it.
Ntop will give you very nice graphs to print out for the guy who needs a clue, showing not only the IPs involved, but the ports, percentages of traffic per protocal/port/whatever.
If they're being used for SPAM, for example, you'll see tons of outgoing port-25 traffic. Just make sure that's not what the box is supposed to be doing!
If this isn't enough for him, and you're sure this is something against the company's policy, bring it to his boss' attention immediately (calmly) with a full explanation of why you are doing so. If you delay this action, you risk having your boss "poison" his perception of the situation, and end up thinking that you're a troublemaker (that is, if the politics are as bad as I'm guessing they are there).
So either fight it all the way, or drop it... or be prepared to find a new job (these situations always suck).
Good, I hope they're hearing that from a lot of people. Google is the kind and size of a company that is needed to get people to switch to Jabber. (I'm talking "the masses" here, not just us geeks)
Hey, I don't see how it could get much better than Google supporting Jabber!
Screw this proprietary crap... the web isn't proprietary (no matter how hard MS tries)... IRC isn't proprietary... email isn't proprietary... why the #@|| should IM be?
Re:Thank you very much!
on
Amorphous Steel
·
· Score: 3, Interesting
I used to work in a machine-shop, both in design and in purchasing (for several years).
Reynolds and many others consider 6061 and 6063 to be marine-grade.
They also consider 7075 to be aircraft grade... twice the shear and tensile strength of 6061, but also twice as expensive (cost/lb).
The T-rating ("-T6") is a hardening that it receives after forming, irrelevant to the alloy.
As far as what is spec-ed out, I agree... you should be able to use 6k series in an airplane, for example in a coffie-pot-holder. Oddly enough, we made a run of those for an airline, and they spec-ed it had to be 7075-T6. And people wonder why air-fare is so expensive... bozos are making the decisions.
The reverse is true too... we made a run of bicycle crank-axles that were spec-ed to be 7075-T9! Hardly an airplane, but those puppies sure were expensive!
I've understood the basics for some time, but the way you put it has to be the most clear description of exactly why it works that I've seen.
Now it makes sense why adding a metal as soft as zinc to aluminum gives you "aircraft grade" (7000 series) alumimum, which is twice the shear and tensile strength of "marine grade" (6000 series) aluminum, which contains the much stronger magnesium instead.
...as soon as someone has released a Linux port (that's stable) for it!
Oh, and they drop the price to around $99 or at least low enough that they're losing a bundle on every one sold, like the current one... anything to help them lose money.;)
It's not difficult to find a REALY hardware modem. Stop wasting your money on what is effectively nothing more than a sound-card with a relay... spend the extra $5 and buy yourself a HARDWARE modem. If it says "softwmodem", click the "next" button and forget you saw it... it doesn't matter how cheap it is if it's junk.
My sister just bought (couple weeks ago) a real, hardware, PCI modem for about $9, so you have no excuse to keep buying crap and supporting the companies who produce it.
Check PriceWatch for the deals... and do a bit of research before you buy 'em!
Sorry if this sounds a bit harsh, but I can't imagine buying five (fake) "modems" and still not figuring it out.
"After a card has rendered a frame/scene, there is no data that needs to be return; it has performed its job."
As I stated in at least 2 postings, if the video is not recombined with extra hardware downstream of the rendering (which as one poster indicated it is, making this a moot point), then the rendered data (which is drastically larger than the pre-rendered data) must be merged with the other card's rendered data in order for it to be displayed. This would require a data transfer over the only medium available to both cards: the bus to which they are both attached. Again, this system (as another poster pointed out) does merge the data externally, so it does not have to make this transfer... so the point is moot.
"So, in recap, if you are saying that with a standard PCI-X or AGP off the shelf motherboard there would very real bottleneck in the BUS causing very real diminished returns for large (maybe not even that large) number of video cards, you are certainly correct."
That is precisely what I'm talking about, since that is what the article is about (y'know, the whole "on-topic" thing?).
"But, if you are talking about graphic rendering in general (which is what I have been talking about), you are unfortunately wrong."
Well yeah, if you have multiple chips doing parallel rendering in a manner in which they share the load without the bus being a factor (like the old 3-chip cards I mentioned in my first post), then it definitely helps... but that's not what the article was about.
"First of all, most devices can access other devices and memory without the CPU being involved. This is what DMA and its ilk are for."
Sorry. While it is true that DMA allows one device to talk to another device without the assistance of the CPU, it still requires the transfer take place over the bus that the devices are plugged into. If the bus is a bottleneck with one card, two makes things much worse.
"Secondly, and I don't know if this is possible or not, but it's possible that two devices on a bus could both be written to at the same time, since they both are listening to the bus at all times."
Nope, not at all. That's not how a bus works... each device is addressed, 3-way calling is not available in this calling area.
"What the heck does the bus have to do with any of it?"
Try unplugging your AGP card and see how well it works.
If the bus were so unimportant, why the heavy focus on the BUS since the original VGA card? ISA->EISA->VLB->PCI->AGP->AGP2x->AGP4x->AGP 8x->PCI x...
If you would actually READ what I posted, you'd understand that first you have to TRANSFER the data to be rendered, then you have to TRANSFER the rendered image BACK so you can TRANSFER it to the other card again. OK, so another poster indicated that the re-merging of the data is done externally, that eliminates the issue with the secondary transfers, but you STILL have to transfer twice as much data s for a single card. If you don't understand this, you REALLY DON'T understand how computers work.
IPC has NOTHING to do with hardware data transfers over a bus. Throwing a big sounding term around doesn't make you smarter.
I've seen laptop pads at the local computer shows for years. They're the footprint of a notebook computer and about 3/4" thick. They have lots of venting, and fans that (I believe) blow out the back.
Unlike the product in the story, this would not only keep your lap cool, but it keeps from overheating your notebook computer by NOT blocking the vents!
"Video rendering is an inherently parallelizable problem..."
Um, no... not at all.
Think about how much bandwidth is needed just for the CPU of the system to feed the graphics hardware that is doing all the work (AGP 1x, 2x, 4x, now 8x and the new PCIx, etc.).
Rendering on two boards means _4x_ the traffic over the bus! Don't believe me? Think about it.. your CPU has to feed card A _and_ card B (2x so far). Then, since you're only displaying on ONE of them, card B has to xfer the rendered display back over the bus to the CPU, then the CPU has to send it back out to card A. Even if card B could directly talk to card A (maybe, my Bt878 card does), that's still 3x the traffic over the bus!
Maybe this is why they claim only a 50% improvement in performance by doubling the hardware.
Slashdot Mirror
I normally don't reply to ACs, but what you're describing can only happen to a power supply that is OFF for extremely extended periods of time, with some other fan causing airflow into it.
Not gonna happen.
Each whisker that hits it will be vaporized long before your hundreds can build up.
Think about how thick a 3A fuse is, the fibers they're describing would have to pile in the THOUSANDS for this to happen, and all at once at that!
No kidding... I mean, if they would have said that they were shorting out the CPU's data bus, or something along those lines it might be believable.
But the POWER SUPPLIES?!?
A microscopic fiber of zinc (a metal with a _very_ low melting point) would not short out ANYTHING with more power than a hearing-aid battery!
As another pointed out already, one of the people interviewed is trying to sell their services cleaning it up!
I would modify this statement to say that it is not common for someone to be
Well, the poster did say that (s)he is a "former programmer", so (s)he doesn't appear to be under (her/)his company's thumb in (her/)his current position.
Then again, it does look like (s)he's trying to make a recommendation of software to evaluate to the company... so the company is already looking for software on the outside... so the below statement is negated anyways.
If you give away your code, others can use it to discover the same patterns; if enough people do that, the pattern will eventually be traded out of profitability.
I used to think that... until I had a long chat with a friend of mine who makes his living (even during/after the market crash!) doing nothing but trading stocks.
I asked him why he posts his recommendations to an open public forum (thinking as you do that it would be bad).
He said that the best thing that can happen is having everyone else buy when (well, immediately after) he does, as it creates a demand for the stock, which drives the price up quickly.
The worst that can happen, is people ignore his post and nothing happens other than he gets a good deal (assuming he's "read" the market correctly).
Either way, (s)he needs to sell (her/)his company on the benefits of releasing Open Source software, which could provide considerable improvement to the software with minimal internal effort.
Since this software is obviously not part of their core business (they're not a software producing company, they're looking to buy it), they would not be losing anything by releasing it under an Open Source license.
Yes, as I stated in my reply (to which you replied), I understand that the ehci would be needed for USB-2.0, and either ohci or uhci would be needed for USB-1.x.
My comment was about the fact that both ohci and uhci drivers were loaded.
Those two are for different chip designs.
The most likely reason for a lack of free software for this application is it's not common for someone to have experience programming and this sort of thing.
You are in this unique position, so I would recommend you start such a project yourself.
The guy who posed the question said he's running RedHat 9, which is a 2.4 kernel based disto... not Mandrake running a 2.6 kernel.
If you're having the same issue, maybe it's because you're using 3 drivers at the same time.
If you have both USB-1.x and USB-2.0 ports on your box I can understand running ehci_hcd for the 2.0 card, but you only need one driver for the other interface.
Frankly, I'm surprized it even loaded both 1.x drivers at the same time.
I ran into this some time back... exactly as you describe - painfully slow printing with little CPU impact.
After some searching I found a hint that it might be related to my USB driver.
Try switching from uhci to usb-uhci (or vise-versa) and see if that makes a difference.
If they're built into your kernel, you'll have to configure them as modules both and rebuild it.
My disposable toy-printer (Lexmark Z35) now works great _and_fast_ in Linux.
Forget running ethereal or other packet sniffers, they're far too fine-grained for what you're trying to do: prove they're being abused.
Connect a small box running your favorite *nix running ntop to the service port (or whatever they call it, I'm half asleep) of the switch/router to which the box(es) in question are connected.
That's it.
Ntop will give you very nice graphs to print out for the guy who needs a clue, showing not only the IPs involved, but the ports, percentages of traffic per protocal/port/whatever.
If they're being used for SPAM, for example, you'll see tons of outgoing port-25 traffic.
Just make sure that's not what the box is supposed to be doing!
If this isn't enough for him, and you're sure this is something against the company's policy, bring it to his boss' attention immediately (calmly) with a full explanation of why you are doing so.
If you delay this action, you risk having your boss "poison" his perception of the situation, and end up thinking that you're a troublemaker (that is, if the politics are as bad as I'm guessing they are there).
So either fight it all the way, or drop it... or be prepared to find a new job (these situations always suck).
Very cool articles... I had NO IDEA about how common that is with copper!
Good, I hope they're hearing that from a lot of people.
Google is the kind and size of a company that is needed to get people to switch to Jabber.
(I'm talking "the masses" here, not just us geeks)
Hey, I don't see how it could get much better than Google supporting Jabber!
Screw this proprietary crap... the web isn't proprietary (no matter how hard MS tries)... IRC isn't proprietary... email isn't proprietary... why the #@|| should IM be?
I used to work in a machine-shop, both in design and in purchasing (for several years).
Reynolds and many others consider 6061 and 6063 to be marine-grade.
They also consider 7075 to be aircraft grade... twice the shear and tensile strength of 6061, but also twice as expensive (cost/lb).
The T-rating ("-T6") is a hardening that it receives after forming, irrelevant to the alloy.
As far as what is spec-ed out, I agree... you should be able to use 6k series in an airplane, for example in a coffie-pot-holder.
Oddly enough, we made a run of those for an airline, and they spec-ed it had to be 7075-T6.
And people wonder why air-fare is so expensive... bozos are making the decisions.
The reverse is true too... we made a run of bicycle crank-axles that were spec-ed to be 7075-T9! Hardly an airplane, but those puppies sure were expensive!
Humor, much like beauty, is in the eye of the beer-holder.
You don't happen to think it's funny that MS lost over $1B last year on the X-box, I think it's hysterical. It's all a matter of opinion.
I've understood the basics for some time, but the way you put it has to be the most clear description of exactly why it works that I've seen.
Now it makes sense why adding a metal as soft as zinc to aluminum gives you "aircraft grade" (7000 series) alumimum, which is twice the shear and tensile strength of "marine grade" (6000 series) aluminum, which contains the much stronger magnesium instead.
Oh, and they drop the price to around $99 or at least low enough that they're losing a bundle on every one sold, like the current one... anything to help them lose money.
(Moderators: this is "humor" not "troll")
If it has "drivers" either with the package or downloadable from the manufacturer, it's not a modem, it's a sound-card pretending to be a modem.
NO modem needs a driver.
They have a standard interface and a standard command-set... just like a keyboard (no drivers).
It's not difficult to find a REALY hardware modem.
Stop wasting your money on what is effectively nothing more than a sound-card with a relay... spend the extra $5 and buy yourself a HARDWARE modem.
If it says "softwmodem", click the "next" button and forget you saw it... it doesn't matter how cheap it is if it's junk.
My sister just bought (couple weeks ago) a real, hardware, PCI modem for about $9, so you have no excuse to keep buying crap and supporting the companies who produce it.
Check PriceWatch for the deals... and do a bit of research before you buy 'em!
Sorry if this sounds a bit harsh, but I can't imagine buying five (fake) "modems" and still not figuring it out.
Actually, yes.
I couldn't agree more.
My very first thought was of all the SPAM I get for anti-SPAM software!
"After a card has rendered a frame/scene, there is no data that needs to be return; it has performed its job."
As I stated in at least 2 postings, if the video is not recombined with extra hardware downstream of the rendering (which as one poster indicated it is, making this a moot point), then the rendered data (which is drastically larger than the pre-rendered data) must be merged with the other card's rendered data in order for it to be displayed. This would require a data transfer over the only medium available to both cards: the bus to which they are both attached.
Again, this system (as another poster pointed out) does merge the data externally, so it does not have to make this transfer... so the point is moot.
"So, in recap, if you are saying that with a standard PCI-X or AGP off the shelf motherboard there would very real bottleneck in the BUS causing very real diminished returns for large (maybe not even that large) number of video cards, you are certainly correct."
That is precisely what I'm talking about, since that is what the article is about (y'know, the whole "on-topic" thing?).
"But, if you are talking about graphic rendering in general (which is what I have been talking about), you are unfortunately wrong."
Well yeah, if you have multiple chips doing parallel rendering in a manner in which they share the load without the bus being a factor (like the old 3-chip cards I mentioned in my first post), then it definitely helps... but that's not what the article was about.
"First of all, most devices can access other devices and memory without the CPU being involved. This is what DMA and its ilk are for."
Sorry. While it is true that DMA allows one device to talk to another device without the assistance of the CPU, it still requires the transfer take place over the bus that the devices are plugged into.
If the bus is a bottleneck with one card, two makes things much worse.
"Secondly, and I don't know if this is possible or not, but it's possible that two devices on a bus could both be written to at the same time, since they both are listening to the bus at all times."
Nope, not at all. That's not how a bus works... each device is addressed, 3-way calling is not available in this calling area.
"What the heck does the bus have to do with any of it?"
Try unplugging your AGP card and see how well it works.
If the bus were so unimportant, why the heavy focus on the BUS since the original VGA card?
ISA->EISA->VLB->PCI->AGP->AGP2x->AGP4x->AG
If you would actually READ what I posted, you'd understand that first you have to TRANSFER the data to be rendered, then you have to TRANSFER the rendered image BACK so you can TRANSFER it to the other card again.
OK, so another poster indicated that the re-merging of the data is done externally, that eliminates the issue with the secondary transfers, but you STILL have to transfer twice as much data s for a single card.
If you don't understand this, you REALLY DON'T understand how computers work.
IPC has NOTHING to do with hardware data transfers over a bus. Throwing a big sounding term around doesn't make you smarter.
"Why didn't someone think of this sooner?"
I've seen laptop pads at the local computer shows for years.
They're the footprint of a notebook computer and about 3/4" thick.
They have lots of venting, and fans that (I believe) blow out the back.
Unlike the product in the story, this would not only keep your lap cool, but it keeps from overheating your notebook computer by NOT blocking the vents!
"Video rendering is an inherently parallelizable problem..."
Um, no... not at all.
Think about how much bandwidth is needed just for the CPU of the system to feed the graphics hardware that is doing all the work (AGP 1x, 2x, 4x, now 8x and the new PCIx, etc.).
Rendering on two boards means _4x_ the traffic over the bus!
Don't believe me? Think about it.. your CPU has to feed card A _and_ card B (2x so far).
Then, since you're only displaying on ONE of them, card B has to xfer the rendered display back over the bus to the CPU, then the CPU has to send it back out to card A. Even if card B could directly talk to card A (maybe, my Bt878 card does), that's still 3x the traffic over the bus!
Maybe this is why they claim only a 50% improvement in performance by doubling the hardware.
Doesn't sound very "parallelizable" to me.