I'm reminded of all the promises we heard for the Transmeta chip, only a fraction of which are being realized. And they have an actual product to demonstrate, mind you.
Really? From what I've read they delivered on everything they said they would/could do. What didn't they deliver on and where was it said they did something that didn't materialize?
I certainly can't ignore such comments. They certainly seem valid to me. Just the same, does your school plan on blocking http and ftp protocols too? What about scp? Do they throttle them? They are all open to abuse. A possible double standand because they have a caching http/ftp proxy?
My point being, ya, it would be nice to have something on the front end to address your plea, but at the same time, people need to be responsible for their impact on a network. A network abuser is a network abuser. Do keep in mind that the standard python client is a reference implemenation, so I wouldn't expect such features to make it there. Just the same, have you contact the author to see how he feels about it? Perhaps he could be talked into asking a couple of questions during installation, like, size of pipe and is it shared? That way, he could automatically create some defaults which are more sane for a shared network. Granted, that still leaves the door open for abuse, just the same, at least you would know it was more than likely abuse rather than someone being ignorant.
One last comment, I do think you have a valid comment which the author may want to hear about. That is, I think you should mention locality preference. If you have multiple files available from the local network, they should float to the top rather than having everything pull from remote networks. Seems logical and valid! If peers are available on the same class a, b, or c network, seems more than logical that those peers should be tapped first.
Well, that's different. You asked about 10k1 support, which ALSA does support, however, the card your talking about is not 10k1 based. Or rather, so says the information at the ALSA site.
So, looks like you're stuck. Have you tried emailing anyone at ALSA or opensource.creative.com to find out if there are any updates? You might email Dell to see what their position is on the issue too. Just letting Dell know that people want an option might be a good start for them.
No idea what you're talking about. Months ago, I used the standard python release of BT and played with throttling it down to 1 k/s. Seems to work fine. Since then, BT has gotten even better at handling bandwidth.
I honestly have no idea what you're complaining about, let alone even talking about.
I noticed the replies to journal entry even point this out. You're not doing anything but spreading misinformation.
--max_uploads
the maximum number of uploads to allow at once. --upload_rate_fudge --max_upload_rate
maximum kB/s to upload at, 0 means no limit (defaults --min_uploads
the number of uploads to fill out to with extra
So on and so on....
All I know is that when I played with these options at 1k/s, I was watching sub-1k/s uploads and downloads.
This is why many databases implement their own caching schemes. I don't recall what-all is included in the new caching and elevator schemes, however, somethings may now be more tunable already.
But,in most cases spammers can't tell what state their Spammees are in.
That's simply not true. If they don't have a good idea who they are spamming, they shouldn't be spamming them. If they don't know their target, then they should not spam until they have a list of email addresses with locations attached. After all, if they don't know where people live, then chances are, they are committing other crimes, like spamming little Johnny about porn and drugs.
BUT that's why I find it strange - if one party determines what everyone else gets, you don't really need XML either.
It's true, you could use some other tool, but the fact that XML has excellent support no matter the enviroment or language, it certainly helps. Add in the fact that something like ASN.1 sucks worse than XML on a really, really, really bad day. Add in the fact that you can optionally support dynamically referenced schemas for on-they-fly updates and validation, supports namespaces, etc., XML is very flexible. It saves people from having to write their own custom parsers (low-level for sure).
I think the key could be what you mention - don't need full element support etc. Still. Are there any other major killer features of XML that will make it the way to go?
Killer features? No. XML doesn't do for you that you can't already do via some other mechanism. Just the same, as far as I'm concerned, me and work associate created XML long before there was something called XML and associated buzz. Why do I mention this? Well, the concept of tags is highly dynamic, highly extensible, easy to automate, and generally easy for humans to read, parse, and even generate. This is exactly why so many years ago, we created our own tag system, which is more or less predates what people call XML today. It's a simple concept serving a need. The fact that we independently created our own version of this technology does seem to validate it has some value. It addressed our needs at the time. Rather well, I might add.
As far as I'm concerned, the big pluses to XML are schemas (dynamically referenced; lending to easy input validation), it's extensibility while maintaining backward compatibility (elements and attributes), and the high quality of generally available tools and parsers in almost any language (C, C++, perl, python, and so on...). For some, namespaces is a key "wow" feature.
Long story short, XML does not live up to it's buzzword-hype, however, it is a valid and viable technology, depending on the problem domain and how it's implemented. It is not a panacea.
all parties involved still have to sit down and decide what they mean when they say something
Except that rarely is how business is done. Rather, one party says, *this* schema says what you will get. Having worked with financial interchange, you would be amazed at how many different and incompatible implementations of the exact same specification you can find. ISO8583 and it's elk are well known for these types problems. With things like XML, it's very straight forward...or should be in all but the most esoteric of interchange needs.
To boot, XML is highly extensible without necessarily requiring, requiring full element/attribute support by all parties. Again, can vary depending on scheme definition and implementation, or even product specification.
So, IMO, interchange is really the only thing that I see XML good at. Again, IMO, storage and DB use, is just plain insane. Flat files or relational databases already work for storage, persistence, and data manipulation, with much lower overhead.
BTW, the simpler design of the Kalashnikov AK-47 rifle was what enabled the Vietcong to prevail over American soldiers equipped with the Stone M-16, which was more advanced.
That's another myth. It was bad politics, plain and simple, that allowed the Vietcong to prevail. You try fighting a war where you can't bomb their factories, not allowed to destroy their air bases, weapon depots, or radar stations. You try winning a war where you can be jailed for actually attempting to win. You try winning a war were most of the S. Vietnam officials were corrupt and giving bad intelligence; the US knew full well this was the case but still continued to heavily use it. Toss in non-professional soldiers and it couldn't of been won with God's own hand. All that, without even talking about the tactics that the Vietcong used.
Once the bullets were changed back to their proper powder, and cleaning kits were finally issued, the m16 proved it self. Likewise, before it was officially issued and cleaning kits were made available and proper ammo was being used, it was in high demand by special forces and other elite units on the ground for "instruction" and "training". The reason being, it was fairly accurate even to extreme ranges (for open sights), light, and they could carry a lot more ammo.
The AK, on the other hand, could be tossed in the mud or in a rice field, let rust, kicked open, and be ready to fire in combat. It's accuracy at medium to long+ ranges *significantly* suffers because of this. This generally wasn't a problem for the Vietcong because combat was generally was short and hand-to-hand ranges.
I remember reading year(s) ago about a card which was supposed to go into a low cost PC which could switch up to 4000 calls. Don't hold me to that number, but it was some very large number. Perhaps this is it finally being deployed.
Really, who cares who did this first. If you think about it, makes much more sense than the Gentoo effort did because this allows people to get a sense of their new hardware capabilities. Without this, the world of 64-bit computing is a tad smaller.
No, not at all. They are given x-dollars per year to recruit and that's how they decided to spent part of their budget. It's been working very well for them. It helps desensitize potential recruits and helps show some of what the Army is about. They are coming with some additional training tidbits and features in the future too.
Even if you don't join the army, the basic first aid awareness offered in the game is enough to help people understand some very, very, basic first aid information.
Overall, I think it's one of the best ways our country could be spending our dollars. After all, it's either this or more people canvassing highschools. What's the difference? If it helps only the really gung-ho join, then that's all the better. If it helps shy away those that didn't "realize" that when you join the army, you might go to war, even better still!
That's because there are a lot of MS haters here which hate that you may know or understand something about MS that they don't. Generally speaking, there are many, many, people that are unfit to manage their own lives and yet they see themselves fit enough to judge other's comments.
Did you notice that at about 11:20, or so, the trading activity jumped significantly? That's odd, considering you said the press release was made at around 11:48. Are we looking at a difference of timezones or what? Insider knowledge?
Everything I've always read about LBX and SSH is that if you plan to use them together, turn off compression in SSH and use it for encryption. Let LBX do it's compression and caching. Likewise, if you don't need encryption, just use LBX. This is especially true if you are latency sensitive. On the other hand, I've seen yet other results which indicated that X over a compressed SSH tunnel, for simple applications, is often faster and lower latency than LBX by it self.
I'm not exactly sure what you're asking? You asking if you get a different animal if you compile out the preempt code too? Meaning, higher performance at the cost of higher latency? AFAIK, the answer is yes.
> Also with hyperthreading, psuedo-SMP is really a lowend feature now.
The problem with that is, enabling SMP support, of which HT is part of, requires additional locking and more overhead to keep things straight in the kernel. To makes matters worse, HT really isn't turning out to be the great-all-around feature that everyone has been looking for. Depending on the application mix you're running, with HT enabled, you may actually see a reduction in performance because of HT. Mix in the additional overhead of having a SMP kernel running on a uniprocessor machine, you may be looking at a significant loss of performance.
As someone just reminded me in another thread, the problem is that you have too many applications fighting for cache, which causes many cache stalls. That, in turn, makes for significant performance loss. Some tests I've seen indicated as much as 30% drop in performance when HT was enabled; with 10%-15% loss the norm. This is the reason why HT is often disabled in the bios of new systems. Of course, if you happen to run a very HT friendly mix of applications, then you may realize a noteworthy increase in performance; something like 10-30%, IIRC.
Long story short, unless you know your application mix is very HT friendly, chances are, you're going to be bleeding if you enable it.
That explains why I remembered reading about "HT aware" applications but I didn't want to mention that because I didn't remember the context at which it applied. Furthermore, and perhaps worse, I simply couldn't remember what "HT aware" meant. You response brought all of that home again!
Linux, more or less does this too. When you compile out SMP support, it effectively changes the resulting code so as to no longer be the same beast. In doing so, it is supposed to save a lot of overhead. I didn't notice if the benchmark results were compiled with SMP support or not, when run on a uniprocessor.
Not all workloads have to scale linearly. It also depends on how the benchmark was configured. Remember, there are many factors which effect scalability, not to mention many subsystems. I don't recall off the top of my head exactly what the benchmark was trying to measure. For example, it could of been trying to measure scalability with high memory contention, or any number of odd cases. In other words, unless the test was specificaly trying to measure CPU scalability, you shouldn't be attempting to place such emphesis on it.
Just FYI, I read this story some time ago on Kernel Trap and I'm too lazy to go look at it again to further offer up details.
Slashdot Mirror
I'm reminded of all the promises we heard for the Transmeta chip, only a fraction of which are being realized. And they have an actual product to demonstrate, mind you.
Really? From what I've read they delivered on everything they said they would/could do. What didn't they deliver on and where was it said they did something that didn't materialize?
I'm not trolling here, I just curious.
I certainly can't ignore such comments. They certainly seem valid to me. Just the same, does your school plan on blocking http and ftp protocols too? What about scp? Do they throttle them? They are all open to abuse. A possible double standand because they have a caching http/ftp proxy?
My point being, ya, it would be nice to have something on the front end to address your plea, but at the same time, people need to be responsible for their impact on a network. A network abuser is a network abuser. Do keep in mind that the standard python client is a reference implemenation, so I wouldn't expect such features to make it there. Just the same, have you contact the author to see how he feels about it? Perhaps he could be talked into asking a couple of questions during installation, like, size of pipe and is it shared? That way, he could automatically create some defaults which are more sane for a shared network. Granted, that still leaves the door open for abuse, just the same, at least you would know it was more than likely abuse rather than someone being ignorant.
One last comment, I do think you have a valid comment which the author may want to hear about. That is, I think you should mention locality preference. If you have multiple files available from the local network, they should float to the top rather than having everything pull from remote networks. Seems logical and valid! If peers are available on the same class a, b, or c network, seems more than logical that those peers should be tapped first.
Well, that's different. You asked about 10k1 support, which ALSA does support, however, the card your talking about is not 10k1 based. Or rather, so says the information at the ALSA site.
So, looks like you're stuck. Have you tried emailing anyone at ALSA or opensource.creative.com to find out if there are any updates? You might email Dell to see what their position is on the issue too. Just letting Dell know that people want an option might be a good start for them.
The official client does and has for a long time already.
No idea what you're talking about. Months ago, I used the standard python release of BT and played with throttling it down to 1 k/s. Seems to work fine. Since then, BT has gotten even better at handling bandwidth.
I honestly have no idea what you're complaining about, let alone even talking about.
I noticed the replies to journal entry even point this out. You're not doing anything but spreading misinformation.
--max_uploads
the maximum number of uploads to allow at once.
--upload_rate_fudge
--max_upload_rate
maximum kB/s to upload at, 0 means no limit (defaults
--min_uploads
the number of uploads to fill out to with extra
So on and so on....
All I know is that when I played with these options at 1k/s, I was watching sub-1k/s uploads and downloads.
Nothing to see here...move along...
Not sure what you think is *way* wrong. It sounds like you exactly understood and got it, rather, you just didn't realize.
You might go back and read what I said and then read what you said and then think for a moment. I'm fairly sure you'll go, "doh!", shortly after.
Doesn't ALSA address that already?
This is why many databases implement their own caching schemes. I don't recall what-all is included in the new caching and elevator schemes, however, somethings may now be more tunable already.
But,in most cases spammers can't tell what state their Spammees are in.
That's simply not true. If they don't have a good idea who they are spamming, they shouldn't be spamming them. If they don't know their target, then they should not spam until they have a list of email addresses with locations attached. After all, if they don't know where people live, then chances are, they are committing other crimes, like spamming little Johnny about porn and drugs.
Not exactly a hard position to defend.
BUT that's why I find it strange - if one party determines what everyone else gets, you don't really need XML either.
It's true, you could use some other tool, but the fact that XML has excellent support no matter the enviroment or language, it certainly helps. Add in the fact that something like ASN.1 sucks worse than XML on a really, really, really bad day. Add in the fact that you can optionally support dynamically referenced schemas for on-they-fly updates and validation, supports namespaces, etc., XML is very flexible. It saves people from having to write their own custom parsers (low-level for sure).
I think the key could be what you mention - don't need full element support etc. Still. Are there any other major killer features of XML that will make it the way to go?
Killer features? No. XML doesn't do for you that you can't already do via some other mechanism. Just the same, as far as I'm concerned, me and work associate created XML long before there was something called XML and associated buzz. Why do I mention this? Well, the concept of tags is highly dynamic, highly extensible, easy to automate, and generally easy for humans to read, parse, and even generate. This is exactly why so many years ago, we created our own tag system, which is more or less predates what people call XML today. It's a simple concept serving a need. The fact that we independently created our own version of this technology does seem to validate it has some value. It addressed our needs at the time. Rather well, I might add.
As far as I'm concerned, the big pluses to XML are schemas (dynamically referenced; lending to easy input validation), it's extensibility while maintaining backward compatibility (elements and attributes), and the high quality of generally available tools and parsers in almost any language (C, C++, perl, python, and so on...). For some, namespaces is a key "wow" feature.
Long story short, XML does not live up to it's buzzword-hype, however, it is a valid and viable technology, depending on the problem domain and how it's implemented. It is not a panacea.
I was getting to respond with the same answer. Someone mod the parent up! Good job!
all parties involved still have to sit down and decide what they mean when they say something
Except that rarely is how business is done. Rather, one party says, *this* schema says what you will get. Having worked with financial interchange, you would be amazed at how many different and incompatible implementations of the exact same specification you can find. ISO8583 and it's elk are well known for these types problems. With things like XML, it's very straight forward...or should be in all but the most esoteric of interchange needs.
To boot, XML is highly extensible without necessarily requiring, requiring full element/attribute support by all parties. Again, can vary depending on scheme definition and implementation, or even product specification.
So, IMO, interchange is really the only thing that I see XML good at. Again, IMO, storage and DB use, is just plain insane. Flat files or relational databases already work for storage, persistence, and data manipulation, with much lower overhead.
BTW, the simpler design of the Kalashnikov AK-47 rifle was what enabled the Vietcong to prevail over American soldiers equipped with the Stone M-16, which was more advanced.
That's another myth. It was bad politics, plain and simple, that allowed the Vietcong to prevail. You try fighting a war where you can't bomb their factories, not allowed to destroy their air bases, weapon depots, or radar stations. You try winning a war where you can be jailed for actually attempting to win. You try winning a war were most of the S. Vietnam officials were corrupt and giving bad intelligence; the US knew full well this was the case but still continued to heavily use it. Toss in non-professional soldiers and it couldn't of been won with God's own hand. All that, without even talking about the tactics that the Vietcong used.
Once the bullets were changed back to their proper powder, and cleaning kits were finally issued, the m16 proved it self. Likewise, before it was officially issued and cleaning kits were made available and proper ammo was being used, it was in high demand by special forces and other elite units on the ground for "instruction" and "training". The reason being, it was fairly accurate even to extreme ranges (for open sights), light, and they could carry a lot more ammo.
The AK, on the other hand, could be tossed in the mud or in a rice field, let rust, kicked open, and be ready to fire in combat. It's accuracy at medium to long+ ranges *significantly* suffers because of this. This generally wasn't a problem for the Vietcong because combat was generally was short and hand-to-hand ranges.
I remember reading year(s) ago about a card which was supposed to go into a low cost PC which could switch up to 4000 calls. Don't hold me to that number, but it was some very large number. Perhaps this is it finally being deployed.
Agreed! XML is horrible at storing data. It is, however, good for interchange.
Really, who cares who did this first. If you think about it, makes much more sense than the Gentoo effort did because this allows people to get a sense of their new hardware capabilities. Without this, the world of 64-bit computing is a tad smaller.
No, not at all. They are given x-dollars per year to recruit and that's how they decided to spent part of their budget. It's been working very well for them. It helps desensitize potential recruits and helps show some of what the Army is about. They are coming with some additional training tidbits and features in the future too.
Even if you don't join the army, the basic first aid awareness offered in the game is enough to help people understand some very, very, basic first aid information.
Overall, I think it's one of the best ways our country could be spending our dollars. After all, it's either this or more people canvassing highschools. What's the difference? If it helps only the really gung-ho join, then that's all the better. If it helps shy away those that didn't "realize" that when you join the army, you might go to war, even better still!
That's because there are a lot of MS haters here which hate that you may know or understand something about MS that they don't. Generally speaking, there are many, many, people that are unfit to manage their own lives and yet they see themselves fit enough to judge other's comments.
Go figure.
Did you notice that at about 11:20, or so, the trading activity jumped significantly? That's odd, considering you said the press release was made at around 11:48. Are we looking at a difference of timezones or what? Insider knowledge?
Any ideas? Explanations?
Everything I've always read about LBX and SSH is that if you plan to use them together, turn off compression in SSH and use it for encryption. Let LBX do it's compression and caching. Likewise, if you don't need encryption, just use LBX. This is especially true if you are latency sensitive. On the other hand, I've seen yet other results which indicated that X over a compressed SSH tunnel, for simple applications, is often faster and lower latency than LBX by it self.
> Is that still true with the Preempt changes?
I'm not exactly sure what you're asking? You asking if you get a different animal if you compile out the preempt code too? Meaning, higher performance at the cost of higher latency? AFAIK, the answer is yes.
> Also with hyperthreading, psuedo-SMP is really a lowend feature now.
The problem with that is, enabling SMP support, of which HT is part of, requires additional locking and more overhead to keep things straight in the kernel. To makes matters worse, HT really isn't turning out to be the great-all-around feature that everyone has been looking for. Depending on the application mix you're running, with HT enabled, you may actually see a reduction in performance because of HT. Mix in the additional overhead of having a SMP kernel running on a uniprocessor machine, you may be looking at a significant loss of performance.
As someone just reminded me in another thread, the problem is that you have too many applications fighting for cache, which causes many cache stalls. That, in turn, makes for significant performance loss. Some tests I've seen indicated as much as 30% drop in performance when HT was enabled; with 10%-15% loss the norm. This is the reason why HT is often disabled in the bios of new systems. Of course, if you happen to run a very HT friendly mix of applications, then you may realize a noteworthy increase in performance; something like 10-30%, IIRC.
Long story short, unless you know your application mix is very HT friendly, chances are, you're going to be bleeding if you enable it.
Great response! Thanks!
That explains why I remembered reading about "HT aware" applications but I didn't want to mention that because I didn't remember the context at which it applied. Furthermore, and perhaps worse, I simply couldn't remember what "HT aware" meant. You response brought all of that home again!
Excellent! Thanks!
You know, the funny thing is, I'm trying to figure out if that's a "good thing" or a "bad thing". :)
Linux, more or less does this too. When you compile out SMP support, it effectively changes the resulting code so as to no longer be the same beast. In doing so, it is supposed to save a lot of overhead. I didn't notice if the benchmark results were compiled with SMP support or not, when run on a uniprocessor.
Anyone notice?
Not all workloads have to scale linearly. It also depends on how the benchmark was configured. Remember, there are many factors which effect scalability, not to mention many subsystems. I don't recall off the top of my head exactly what the benchmark was trying to measure. For example, it could of been trying to measure scalability with high memory contention, or any number of odd cases. In other words, unless the test was specificaly trying to measure CPU scalability, you shouldn't be attempting to place such emphesis on it.
Just FYI, I read this story some time ago on Kernel Trap and I'm too lazy to go look at it again to further offer up details.