Search This Blog


Saturday, September 26, 2015

Volkswagon - Teaching to the Test...

I find it quite ironic that VW (Volkswagon) is caught prepping vehicles (with software no less) so that they pass tests on the test stand but fail in real life to the delivered the promised "clean air" performance while here in the USA "teaching to the test" is what millions of grade school kids are taught every day.

So teaching to the test would appear to have consequences.

So, no doubt, the little gnomes at VW working on the software (of course I'd like to see the actual, concrete evidence of this) figured, ah well, its just a test.  We were taught that doing what's needed to pass the test is what we should focus on, so let's focus on it...

Next point - at least so far there is no actual evidence that software was deliberately written to cheat.   We see a lot of statements like this (from here): "For years, millions of Volkswagen’s deisel cars contained software that turned their pollution controls on only when the cars were being tested by regulators."

So how do the cars know the "regulators" are testing them?

Deliberately writing software for cheat would have to require that there were a very specific set of real world circumstance that occurred only during a test - otherwise the performance would be uneven and customers would complain.

It would be nice to see emails or other confirming documents.

If we think all this through we would have to draw some conclusions:

Either the tests the EPA uses are so unrelated to actual driving that they are useless (hence the evil gnomes took advantage of that fact that the conditions were SO OBVIOUS they could build software to test for them)

Or its just happens that when VW cars are doing what they do they are more pollution conscientious when doing what the EPA tests for, i.e., the EPA tests are just stupid and measure nothing useful.

It will be fun to watch all this play out...

Saturday, August 1, 2015

An Ars Technica "Audiophile" Testing FAIL

Note the audio files on the Synology
(For more than fifteen years I worked with a commercial system I developed that delivered massive amounts (terabytes) of NAS data in real time in a commercial printing scenario.  During that time there was not, as far as I know and we handled all the support, a single data error related to the streaming of data from the NAS.)

I stumbled upon and started to read an Ars Technica article called "The Audiophile's Dilemma" - I thought at first it was about whether you could hear the difference in audio cables, e.g., a speaker or microphone cable.  (Some people claim to be able to hear, for example, that a gold-plated connector sounds "better" than one that is not gold plated.)

Always an interesting read.

But this article was different...

The idea was whether or not you could hear the difference using an expensive ($340 USD) networking cable.

But not by sending audio over it!

Instead, the cable was being used as a network cable hooked to a standard ethernet switch.  Not passing audio over the cable but simply file data (SMB-style block transfers between an NAS and a computer one supposes).

So, according to the article "The test setup had the Synology DS215j connected by a standard Ethernet cable to the switch and the laptop connected to the same switch by the cable under test" and a "Dell M2800 laptop to serve as a listening station."

The Synology is a box (see this) containing storage, in the case of this test two "Digital WD Red 1TB WD10EFRX" drives.

So effectively we have a laptop with attached storage via the "cable under test" through a switch to the Synology.

The extracted audio (to be listened two comparatively) was a 30 second clip from a CD.

CD's are typically 44.1kHz sampled so we are talking about a 1.5Mb of audio data (x2 for stereo, though according to the above image we've got about 5.5Mb of audio data...).

In any case one supposes that a Windows audio player is being used to play these files for the comparison test (no mention I could find of which one or how it was set up).

So, let's pause right here for a second and think about this...

We are going to play audio files on a laptop from a connected network storage.  Network storage connected via a 1Gbit switch ("One Netgear ProSAFE 5-port gigabit Ethernet switch, model GS105NA" according to the article).

The drives are rated 150Mb/second and the Synology around 111Mb/sec (see this).

We are supposedly going to compare the "audio quality" of data transferred via different network cables used between the network switch and the laptop.

I guess those involved in this, Lee Hutchinson (the author from Ars and the James Randi of the James Randi Educational Foundation (JREF)), imagined they were "playing" the audio files over the switch through "cable under test" in such a was as to potentially "hear" the difference in cables.

However, this seems to me to be, well, basically, impossible.

For one, the entire 5Mb of audio, given the configuration described, would move from the Synology to the laptop in, say, 50 milliseconds (50ms).  Most likely (and this part was not described in the article) the audio player would open the file (or have it held open) and the OS (Windows I supposed) and/or the audio player would likely buffer the file data (some or all of it).  This means that once you clicked on play the audio player would (worst case) load the entire file into memory and then start playing it.

This is not described by the article though it seems quite unlikely that the audio player is reading data one byte or even one block at a time.

(The NAS probably looks like a local drive to Windows and the audio player so both would assume that it was "local", i.e., a local disk, and simply assume the transfer to memory would be immediate as opposed to playing a file via a WiFi connection where there would be latency.)

Nor should a configuration like this be confused with network "streaming" where audio bytes flow as needed across network connection.

NAS tries to make the storage look and act like a local, fast disk which means that its running SMB-like protocols with block transfers, not streams of audio "bytes."

Further, the actual procedure described of "switching cables" and playing audio does not describe whether the audio was "refreshed" (or flushed) each time, i.e., once loaded in the audio player and the cables were being switched did the audio even get read from the NAS after the first time it was loaded and played (things like OS buffering, NAS architecture, etc. all come into play on this).  The entire clip, for example, (tiny at 5.5Mb) may have just sat on the audio player (or in the OS disk buffers) after the first use.

The file sizes involved are very small relative to OS and NAS buffering sizes.  We also don't know the frame sizes used for networking and its entirely possible the entire file moved across the network in only a few frames at 1Gb/sec.

Audio players typically buffer data when clips start playing to ensure that there is no skipping or jitter - how big are the buffers in this case?

Regardless of these points the move of the data from the NAS to the laptop is basically guaranteed to be error free by the networking protocol.

Without extensive knowledge about what was done and, more importantly, the specific details of the audio play, OS, drivers, etc. etc. there is no way to know what was happening for sure other than to say the supposed "quality" of the cable is not an issue.

Given my experience with these sorts of things what they imagined they were doing and what actually happened are certainly two different things entirely.

Then there is the issue of what people appear to think is happening with "interference" on the cable.

Twisted pair ethernet is the physical connection between two points in a network.  The layers above the connection handle ensuring that data moving over the network occurs without error.

And this is key.

If audio data were moving over a twisted pair then one would imagine that interference would matter (and could be "heard" by a listener).

In this case we are sending blocks (most likely SMB-style blocks of file data) from one point to another.

If twisted pair ethernet were at all noisy at the higher network levels nothing on the planet using twisted pair would work for data.  As for the cable quality - the point of something like twisted pair is to send a differential signal which is likely to be more immune to noise than an unbalanced signal.  Secondly, ethernet by nature is not "clean" - frames interfere by design on the wire.  The purpose of the higher protocol levels is to ensure that the delivered data is clean and error free.

These fools even write about how the expensive twisted pair cables are "directional."  Apparently it matters which end you plug in where (perhaps at the limits of 1 Gb/sec transfer speeds but not for moving a paltry 6Mb of data around).

So these poor bastards seem to be confusing "quality of cable" in a NAS-style data role with "sound quality."

They appear to have no idea what-so-ever about audio, NAS, audio and audio software, buffering, how NAS works, how OS software works, nothing!

They are not testing what they think they are testing.

And this is sad.

Poor old James Randi is sucked into this debacle of stupidity right along with the author.

So the idea was that the author and Ars and, I guess James Randi, believed that they were somehow testing the audio quality of data over a network cable when in fact they were testing nothing of the sort.

When I was a boy I was always interested in science and technology.  I would conduct what I thought were "experiments" and showed amazing things.

However, whenever I showed these experiments to "grown ups" they would always point out how what I thought was going on was in fact merely what I had fooled myself into believing.

Sadly, today this would be appear to be what a lot of science has become.

Tests so ill though out that they are meaningless - yet, as in the case of this article - still presented as meaningful.

Tuesday, July 28, 2015

Autonomous Life and Death Decisions...

So the Future of Life (FOL) organization thinks AI-based weapons are bad and that they should not be developed.  According to the linked document above these weapons could include things like "armed quadcopters that can search for and eliminate people meeting certain pre-defined criteria."

The concern, apparently, is a "global AI arms race."

Interestingly, though, cruise missiles are explicitly excluded.  Cruise missiles, at least in the opinion of the FOL folks, don't involve "AI" even though they make their own targeting decisions (or at least not the right kind of "AI").

So Elon Musk, a signer of the FOL document linked above, thinks that one day "non-self-driving" cars will be outlawed...?"  Musk says: "I don't think we have to worry about autonomous cars, because that's sort of like a narrow form of AI ... It's not something that I think is very difficult, actually, to do autonomous driving, to a degree that's much safer than a person, is much easier than people think."

So I guess there are degrees of AI, narrow to what? "wide?"

What about the "ethics" of self driving cars?

Supposed a small, "unseen" child darts out from behind a parked car leaving no time to stop.  In the on-coming lane is a pregnant mom and another infant.  What does the "self driving car" AI decide to do?

If its "narrow" perhaps it simply runs over the child...

Or maybe it instead decides to kill the mom in the on-coming lane.

If its not so narrow maybe some quick facial recognition could be used to decide if any of the potential victims of the accident are "haters", religious folk, or other undesirables who there are too many of in the country.

How would you know if the AI wasn't making these kinds of decisions?

What if there was some sort of "disparate impact" on certain segments of the population relative to the decisions made by the self driving cars?

I don't really think a "global AI arms race" would be the problem...

Wednesday, July 22, 2015

Command Lines of the Future...

Lest anyone thought I was kidding when I wrote this recent post on how command lines are making a comeback, i.e., as you text your bank 'move $100 from checking to savings' to get things done, I now offer CSound.

You can see the details here at Motherboard.

So now, to compose and/or play music live I can write commands (or Lisp functions if you prefer).

Sure glad I took typing in 10th grade...

Sunday, July 12, 2015

Apple: The Bigger They are the Harder They Fall...

I have posted on the slow demise by Apple (see this and this).

Slowly but surely this has progressed.

I have not installed the latest OS X and hope not too.

Here is Forbes saying the same thing.

The bigger they are the harder they fall...

Tuesday, June 30, 2015

Where's the Objective Scientific Evidence for the Dangers of Diacetyl and Acetyl Propionyl?

I came across a blog called  In particular this post stands out:

Basically its a discussion about how a UK lab and company called Cloud9 tested an e-liquid called Five Pawns.

The crux of the article is a table that shows the following data:

vapemestoopid says: "Five Pawns told more than one company in the UK that their liquids were DIACETYL and AP FREE. Not to mention how many in the US? Not to mention numerous email replies to consumers found during a simple google search. Dating back to 2013 from US, Australia and Greece."

vapmestoopid supplies the following three images (copied from their blog - link above):

So here we see Five Pawns claiming no Diacetyl or acetone.  Now acetone is not Acetyl Propionyl (AP) - a miss spelling?  Perhaps, but by how - its all greek to me...

And here we see Five Pawns claiming no Diacetyl - no mention of AP.

And here is some hearsay from GrannyGrump.

So as best I can tell Five Pawns claims not to use Diacetyl - nothing about AP anywhere except in the mind of vapemestoopid...

Not surprisingly Five Pawns claims the Cloud9 results are baloney:

Here is the summary of Five Pawn's latest test numbers:

All but "Perpetual Check" have no detectable diacetyl according to their lab.

However, they do test positive in a number of flavors for 2,3 Pentadedione (AP).

What's interesting is the AP results all seem off by about a factor of between three and five.

So the conclusion of vapemestoopid and Cloud9 is apparently that e-liquids with "high" levels are dangerous because of this study, among others.

Indeed the referenced study cites other well known studies that have appeared elsewhere here and on Facebook and various vaping sites.  However this document also says things like:

"Regarding the combination of flavorings with propylene glycol and glycerin in aerosols, specific concerns exist for lung and cardiovascular function: 1) propylene glycol or glycerin alone may elicit pathophysiological and/or pathological changes in lung function; and 2) interactions between the effects of the individual agents may heighten toxicity."

Effectively all flavors and PG and VG might be bad in some way, also nicotine, for you to inhale.

The bottom line here seems to be that, "OMG, vaping certain flavors might be bad!"

So some arbitrary flavors are picked out - diacetyl and a variant of it, AP.

Why these?  They relate to the infamous "pop corn lung" incidents.



Please read these.  The bottom line is no one, not the FDA or the CDC, has any real idea what happened with these incidents.

So I think a couple of things:

1) Running around testing e-liquid and publishing results without documenting the process in specific detail seems stoopid.  For example, the UK lab (according to Cloud9 uses "[the] same independant UK-based lab used by Trading Standards." - whatever that might mean) and the US labs, one would hope, would express how they do their work and how they calibrate and handle their processes, samples and equipment.

In addition one would hope that multiple samples and multiple labs would be used in a double blind study to ensure that both properly calibrated test samples as well as commercial samples are effectively intermixed during testing.

(This kind of testing is what a vaping trade association should do. My suspicion is that many are duped into paying money for bogus processes and results.)

2) The problem, as stated here on this blog as well as in the Five Pawns blog is this: "Further, we feel that efforts to translate industrial exposure limits to vaping exposure limits are flawed. It is clearly not the same.  If this were true, one would expect a population of individuals becoming sick from vaping, but this is not the case (underline mine). There are no known publicly documented cases of anyone having respiratory issues related to vaping AP or diacetyl at the levels currently in e-liquids.  Many websites and blogs discuss this exact issue.  We are confident that studies and future data will show inhalation from vaping e-liquids should not be compared to industrial exposure limits." - basically there has to be a reason vaping and smoking are not killing people due to DA or AP.

Until this issue is scientifically vetted panicking and screaming "Danger Danger" about DA and AP is really scientifically bogus and very misleading for consumers.

Is there a risk? Of course.  There is risk in breathing and in smoking.  Is smoking a greater risk than vaping?  Is it in the best interest of the consumer to continue smoking until, decades from now, all this is resolved?


3) Testing results for DA and PA can and do vary over the life of an e-liquid bottle (again from the Five Pawns blog): "We have funded extensive independent research, including inhalation and heat studies, and have plans to begin in-vitro research as well, looking at the effects of e-liquid vapor on lung tissue.  In our research, we have also discovered that the effects of storage conditions and time on the shelf can also affect the variability of test results (underline mine).  Therefore, we have also initiated long-term stability and degradation testing, which can take up to two years for results."

So testing not only has to be calibrated relative to amounts but it must be applied comparably across testing environments and samples relative to the "age" of the liquid, exactly how the testing is done, and so on.

4) There are many other questionable ingredients like cinnamon which no one seems concerned with yet are demonstrably and objectively "worse" than DA or AP in terms observable of impact on body tissues in humans.  Selecting a small subset of some of these flavors (like DA and AP) but not others is also very misleading for consumers.  Yet I see no hew and cry for their removal from e-liquids.

The bottom line here is really simple:

Cigarettes are known to be significantly more dangerous than virtually all forms of vaping at this time.

DA is already in cigarettes (and vaping for that matter) at comparable levels to the "panic" levels described by vapemestoopid and clould9 yet apparently neither causes OB.

Without an scientific explanation of this fact its really disingenuous to make claims DA or AP are dangerous.

One must also consider the danger of leaving people on cigarettes until the "safety" of vaping is confirmed.

This is like telling children to wait in the burning second floor room until a proper, government approved ladder is available to rescue them.

Panic mongering is not good for anyone...

Monday, June 29, 2015

More Google "Don't Be Evil..."

In May of 2012 I wrote "Google's Waterloo, Patent 6,061,520."

Google's claim was that an API was basically unpatentable.

It looked like Google would be taking Oracle to the cleaners by freely using its Java APIs.

But in a surprise move the US Supreme Court has declined Google's recent appeal on the matter and has thus breathed new life into Oracle's claims (see this WSJ article).

As I wrote before I believe its completely preposterous for Google to claim that an API is not a copyrightable item.

According to the WSJ article: "Google had asked the Supreme Court to hear the case and limit how software makers could use copyright law to assert exclusive rights over computer programs. It argued Oracle shouldn’t be able to claim copyrights on basic software commands."

Really - anyone can just take software written by anyone else just because they invented "basic software commands?"

Sure sounds like a money grab on Google's part to me....