User talk:Dsimic/Archive 5

This is an archive of past discussions with User:Dsimic. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 1

←

Archive 3

Parallel ATA

Peripheral devices do not "primarily interact with humans". Anything outside of the CPU and main memory is considered a peripheral device. This includes hard disk drives and tape drives. Note the wording in the standard, quoted in the section on ATA-2. Jeh (talk) 19:15, 17 May 2015 (UTC)

Hello! As far as I've been taught about it, peripheral devices collect and present information in human-readable form, and that's what I've referred to in my edit. Surely, I'd need references to cover that, but some of the available online sources go as far as describing RAM as a peripheral device, what's an absolute nonsense (like this one, for example, but I've seen another one that explicitly calls RAM a peripheral device). RAM should be a peripheral device, while a PSU isn't? Then what about laptops and small-form-factor computers having their PSUs as power bricks? — Dsimic (talk | contribs) 19:32, 17 May 2015 (UTC)

While looking at the quotation in Parallel ATA § EIDE and ATA-2 section, it's clear that the ATA-2 standard defines a device as "a storage peripheral". However, I'm not sure how much is that enough for the general definition of peripheral devices, as other available sources don't make much sense by putting almost everything into that category. — Dsimic (talk | contribs) 19:47, 17 May 2015 (UTC)

A PSU is not a peripheral device. Nor is RAM. By what I was taught about it, backed by numerous computer makers' product literature from which I've spec'd major installations, storage devices are peripherals. Recent marketing trends have been to list human interface devices as "peripherals" and not e.g. hard drives, but that is a recentism. If you write data to it or get data from it with I/O commands, it's an I/O device and therefore a peripheral, whether or not the device presents or accepts data in human-compatible form. Jeh (talk) 19:58, 17 May 2015 (UTC)

Hm, but you can also use I/O commands to communicate with a fan speed controller or a SATA controller, for example, which are part of a modern computer motherboard. Furthermore, you can even use I/O commands to talk to a CPU's integrated memory controller. That should classify those few examples as peripheral devices, but I'm not sure how much they are. Of course, all this isn't that much important, but I'd say it's an interesting thing to be discussed. :) — Dsimic (talk | contribs) 20:33, 17 May 2015 (UTC)

PCI Express article illustration

I added this cause it is not a simple closed 1x connector and the photo quality is better than the present one. Somebody disrupted the description and the you removed it. --Hans Haase (有问题吗) 21:22, 20 May 2015 (UTC)

Hello! As I've described it in my edit summary, positioning of the File:PCIe J1900 SoC ITX Mainboard IMG 1820.JPG picture looked rather bad in the lead section, and there's already a picture of different slots in the PCI Express § Form factors section. Though, unfortunately I've missed the fact that the picture shows an open-end ×1 connector, sorry for that and thank you for pointing it out! Thus, I've readded the picture into the PCI Express § Physical layer section, where it should fit rather well. Hope you agree. — Dsimic (talk | contribs) 21:46, 20 May 2015 (UTC)

Multitasking for newbies

Not to discredit your efforts, you totally missed the point, i.e., education of newbies. The frames of a motion picture were included to explain the multitasking concept to newbies who are likely to misconstrue the term multitasking, said term often being interpreted as simultaneous, e.g., texting and driving, in the popular media. The CPU, no matter how configured, must interleave chunks of multiple processes. Just as a camera switching back-and-forth between incomplete scenes will.

Note: My object is to make the concept clear and comprehensible, not to impress fellow IT professionals with recondite distillations of fact. For a professional who does not need it, your definition suffices. However for a newbie, it's too tight, and self-contradictory, even. That said, I'm butting out, as you've made quite a spectacular effort at various corrections, and I honestly don't have the time to engage. We'll go with your edit. But it, no offense, could be better. 99.246.121.36 (talk) 00:16, 22 May 2015 (UTC)

Hello! Regarding my edit on the Computer multitasking article you're referring to, I still think that such analogies are rather redundant. True, Wikipedia articles should be written in a way that requires no prior knowledge, but how far should that be stretched? If stretched far enough, each article could be started with an introduction of the English alphabet. :) Also, the rest of the Computer multitasking article provides a rather good further overview, so everyone going all the way through the article should end up with a solid grasp of the concept of multitasking. — Dsimic (talk | contribs) 00:46, 22 May 2015 (UTC)

Here's an attempt at making the Computer multitasking's opening paragraph more readable and understandable; IMHO, any further "dumbing" of the initial description would be rather pointless. — Dsimic (talk | contribs) 01:12, 22 May 2015 (UTC)

USB type-C redirect

Why did you revert my change at USB Type-C when a section named "USB Type-C" of the redirect's target exists? Someone added the section to page USB last month. At the time you created USB Type-C as a redirect, it was not there. I redirected to USB#USB Type-C so that readers could focus directly on USB Type-C. I also moved the anchor TYPE-C to the section, in which I placed {{Anchor|USB Type-C}} inside. I have already checked the edit history of the redirect page before I updated the redirect. Give reason for reverting other than to repeatedly say Explicit anchors are preferred, as they stay effective even if sections are renamed in your edit summary. --24.6.161.63 (talk) 23:29, 18 May 2015 (UTC)

Hello! As explained in my edit summary you've quoted above, I've reverted it because explicit anchors (those introduced by the {{Anchor}} template) are much better in redirects than section titles. If the article sections are renamed later, split into two or more (sub)sections or altered in another way, explicit anchors are moved to appropriate new positions in the article (exactly as you did it after USB § USB type-C subsection has been split off from USB § USB 3.1), with already existing redirects still working without requiring any changes to them.

Furthermore, there are more redirects pointing to the same position in the USB article, including the USB Type-C, USB type-C and Type-C redirects, and all of them simply continue to work as expected after the explicit "TYPE-C" anchor is moved to a new position within the USB article. With all that in mind, there should be no reasons not to use explicit anchors in redirects. Hope you agree. — Dsimic (talk | contribs) 07:25, 19 May 2015 (UTC)

I am sorry for errors in my above message. Actually, what I meant is "USB Type-C", which is intentional. I incorrectly redirected the page USB Type-C to the anchor USB Type-C as the subsection's title is case-sensitive, but the anchor worked naturally. The actual formatting header where I modified is ====={{Anchor|TYPE-C}}USB type-C=====. The "TYPE-C" anchor seems to be customary by you, but you are not only one that prefers this. I notice that another editor created a redirect as USB#TYPE-C at page Type-C. I mean the text USB#TYPE-C.

The subsection at the USB article was added when the new Apple MacBook, which has only one USB 3.1 Type-C port, was out for sales. (See the article MacBook (2015 version).) The "TYPE-C" text had remained inside a parameter of the {{Anchor}} template for about another month, until I edited and then saved the page. It is now inside the sub subsection header.

As for your edits to USB Type-C, you have used the same edit summary twice. What do you mean, "explicit" you use to modify noun "anchor"? I assume most editors redirect a page to a native anchor like "USB type-C", rather than "customary" anchors like "TYPE-C" that do not exactly match title of any section header. Native anchors in wiki are tags that render an exact title's section link naturally.

I have to disagree with your version. Do you think they do the same or redirect a page to a section title naturally? --24.6.161.63 (talk) 22:37, 19 May 2015 (UTC)

I just checked your recent contributions, and noticed you changed "Type-C" to "type-C" across the USB article. That confused me at the time of my previous writing above. --24.6.161.63 (talk) 22:52, 19 May 2015 (UTC)

No worries about the errors. Everything I wrote above is based on my experience here – I've seen numerous broken redirects because the sections they have pointed to got renamed etc. Moreover, people tend to create redirects to sections, and place comments such as  right below the sections such redirects point to. That's simply wrong, as nobody knows later how many such redirects are there in case such sections need to be renamed, and that requires digging through the "what links here" to keep such redirects working. In other words, IMHO things people do naturally are not necessarily the best things to do.

Speaking about the "explicit anchors" in my edit summaries, "explicit" modifes "anchor" so it refers to anchors explicitly added to articles, by using the {{Anchor}} template, instead of the anchors implicitly created as a result of placing section headings. Maybe that wouldn't be everyone's choice of a modifier, but it seems logical to me: implicitly means that something hasn't been required explicitly. — Dsimic (talk | contribs) 22:55, 19 May 2015 (UTC)

The template is not needed because the {{Anchor|TYPE-C}} text would appear between /* and */ (which renders section linking) in edit summaries. It is undesirable, unlike tags such as <this>. The page should redirect directly to a section currently named "USB type-C", not "TYPE-C", which I think is too broad. It is unclear to me whether the capitalized term most commonly refers to a new type of USB. --24.6.161.63 (talk) 23:28, 19 May 2015 (UTC)

Why should it be important how it looks in edit summaries offered by default when editing sections? It's about the redirects, not about edit summaries. — Dsimic (talk | contribs) 23:33, 19 May 2015 (UTC)

Because it breaks a section link in an edit summary, just like removing the template from a section header while an explicit anchor is linked from a redirect, it breaks the anchor link as well. --24.6.161.63 (talk) 00:05, 20 May 2015 (UTC)

There are no actual section links in edit summaries. — Dsimic (talk | contribs) 00:20, 20 May 2015 (UTC)

Yes, they do. For example,

/* {{Anchor|PD|PD-R1.0|PD-R1.0V1.1|PD-R1.0V1.2|PD-R2.0V1.0}}USB Power Delivery */ The devices have increased power requirements, not increased energy requirements, fixed error.

generates "→{{Anchor|PD|PD-R1.0|PD-R1.0V1.1|PD-R1.0V1.2|PD-R2.0V1.0}}USB Power Delivery: The devices have increased power requirements, not increased energy requirements, fixed error." in edit summary. Clicking the "→" will take us to that section, but there is no such section called "{{Anchor|PD|PD-R1.0|PD-R1.0V1.1|PD-R1.0V1.2|PD-R2.0V1.0}}USB Power Delivery" in the USB article. (diff link) That is what it is broken if the section is in fact "USB Power Delivery". Regarding one of your edits to the USB article, did you actuallly delete the part of "{{Anchor|TYPE-C))" in edit summary when you edited the section "USB Type-C", in this diff? --24.6.161.63 (talk) 06:02, 22 May 2015 (UTC)

That's a good point, I've never examined those right arrows available in edit summaries. However, IMHO that slight inconvenience isn't a good enough argument against using explicit anchors. Yes, I always trim section "hints" offered by default in edit summaries so they contain only the section titles, as that makes them much more readable in edit histories. — Dsimic (talk | contribs) 18:57, 22 May 2015 (UTC)

Arduino official website

Thank you for diff 663477834. Please, check the global edits of the user, this was massive change in several wikis (I fixed ru: and de:) - [1] a5b (talk) 02:28, 22 May 2015 (UTC)

Hello! You're welcome, and IMHO only including both arduino.cc and arduino.org is as neutral as possible. If there's a later resolution of the currently ongoing legal dispute, we can update the Arduino § External links section so it contains only one link to the official website. — Dsimic (talk | contribs) 19:03, 22 May 2015 (UTC)

Open vSwitch performance improvements

I noticed my input on performance improvement was undone. Could you please clarify and advise so I can update it so that it is acceptable? Thanks Rob — Preceding unsigned comment added by Robpater (talk • contribs) 01:45, 27 May 2015‎ (UTC)

Hello! Regarding your edits on the Open vSwitch article, they haven't been undone; instead, I've extracted valuable parts from them and integrated those into the article. Please don't get me wrong, but the way you've described it sounded like some kind of a PR campaign, instead of remaining neutral and presenting significant facts about Open vSwitch.

For example, Wikipedia articles shouldn't present that being "fast and efficient" is important for the "market success of Open vSwitch"; at the same time, weasel words such as "high overhead needs to be resolved to significantly improve throughput", "there have been a number of initiatives to accelerate OVS performance", or "efficient use of computing resources [...] without compromising performance predictability" add very little value to articles.

What I've incorporated into the Open vSwitch § Features section, based on the references you've provided, should cover the facts about performance improvements well enough without going into unnecessary details. Hope you agree. — Dsimic (talk | contribs) 02:16, 27 May 2015 (UTC)

Thanks! I did not notice your additions at first. What I was trying to convey is the move to carrier virtualization from IT virtualization, requires enhancements to OVS to become carrier-grade in terms of performance and scalability in order to meet the needs of the public network (ie for NFV). Do you think adding something along this line would be useful for the OVS page? If so your advice would be v helpful. Thanks Rob Robpater (talk) 01:15, 28 May 2015 (UTC)

You're welcome. IMHO, for now it might be better to leave such descriptions to the Network functions virtualization article, as the Open vSwitch article in its current form doesn't go too deep into various aspects. Also, recent "hot" work on improving the performance of Open vSwitch seems to be taking place in a couple of commercial products that keep their descriptions rather blurry and at the level of PR announcements. At the same time, PR announcements in general border with what's considered reliable sources as companies almost always tend to be a little biased in their PR announcements. Hope you agree. — Dsimic (talk | contribs) 03:27, 28 May 2015 (UTC)

Init, runlevels and modern Linux distributions

There are no run levels in most modern Linux anymore so the "Default runlevels" should be trimmed down (the edit you reverted) or marked as historical. Please let me know your thoughts.--Tim (talk) 14:35, 27 May 2015 (UTC)

Hello! In my opinion, it should be better to mark those descriptions (the one in the Init article, and, perhaps, the other one in the Runlevel article) as tied to particular Linux distribution versions instead of simply deleting them. Older versions of those distributions, which don't use systemd, are still supported and used in different environments; for example, CentOS 5 is still widely used and it comes with the traditional init. Thoughts? — Dsimic (talk | contribs) 03:45, 28 May 2015 (UTC)

Hack of {{n/a}}

Hi Dsimic! I did partially revert your changes to Standard RAID levels and Nested RAID levels. I do not see that use of the {{n/a}} template as being the intended use, since in neither table are the cells actually not applicable.

If your concern is that the {{Depends}} and {{Unknown}} templates are too boldly formatted, I happen to agree with you. However, I don't agree that the appropriate fix is hacks or manual cell formatting on the article side; rather, the template should be changed (with discussion, of course) so that your concern is addressed globally, and consistently. – voidxor ^{(talk | contrib)} 20:44, 22 May 2015 (UTC)

Hey, Voidxor! On second thought, I agree that using {{Depends}} and {{Unknown}} templates is much better than "customizing" the {{n/a}} template. However, those two templates might benefit from a modification that would make them stand out less, which applies especially to the {{Unknown}} template that makes the table in Nested RAID levels § Comparison section look almost funny. Though, that might be just up to the table being almost empty? Perhaps the {{Unknown}} template actually looks good in tables with only a few empty cells, where its visual appeal is actually desirable, so it shouldn't be modified at all? — Dsimic (talk | contribs) 21:06, 22 May 2015 (UTC)

I just switched the {{Unknown}} templates to {{Dunno}} instead. Hope that helps. If you still feel those templates are too flashy, a proposal to change them will get my support. – voidxor ^{(talk | contrib)} 06:53, 24 May 2015 (UTC)

Current look	—	?	Unknown	Depends
Proposal #1	—	?	Unknown	Depends
Proposal #2	—	?	Unknown	Depends

Thank you, switching to {{Dunno}} makes the table look much less "busy". I've been thinking more about those templates, and it might actually be good to have a little bit more "flashy" {{Unknown}} template so it actually draws attention of people who might actually fill in the voids. That way, once the empty cells in Nested RAID levels § Comparison section lose their majority status, we might actually want to go back to {{Unknown}}.

However, in my opinion it might be good to make all those templates a little more uniform. A small comparison I've prepared here contains two proposals: #1 turns the text color into gray in all templates, while #2 turns it into black. IMHO, having them all in gray looks better as more subtle, but there are numerous other templates (such as {{Yes}}, {{No}}, {{Good}} or {{Bad}}, as visible in Template:n/a § Templates, for example) so turning the text in the only exception (which is {{n/a}}) into black might be actually more feasible. Thoughts? — Dsimic (talk | contribs) 11:39, 24 May 2015 (UTC)

Proposal #3	—	?	Unknown	Depends

Sorry for the delay in responding; I've been off wiki. In my opinion, non-answers to table cells should indeed use gray text. If you think about it, {{Depends}} is actually a possible answer, whereas {{Dunno}} and {{Unknown}} are for cells in need of answers, and {{n/a}} is for cells that will never receive an answer. Therefore, I would vote for graying-out {{Dunno}} and {{Unknown}} as is shown in proposal #3, yet leaving {{Depends}} and {{n/a}} as is. We might make {{Dunno}} and {{Unknown}} <small> to further lessen their busyness.

Also, {{Dunno}} and {{Unknown}} serve the same purpose. I would support a merging these redundant templates. One would simply be redirected to the other to keep existing code working. – voidxor ^{(talk | contrib)} 23:22, 28 May 2015 (UTC)

Proposal #4	—	?	Unknown	Depends
Proposal #5	—	?	Unknown	Depends
Proposal #6	—	?	Unknown	Depends

No worries about the slight delay, there's no hurry. That's a very good point – with such color-coding in place, gray and black colors would clearly indicate whether a cell is a fill-in request or not. The only thing I'd add to your proposal is that {{n/a}} should have its label in black (as visible in the proposal #4), as that template represents pretty much a definitive answer: "not applicable" or "not available" (for the latter, in the sense of "no such thing", not "unknown"). How about that? Of course, I'd support the merger between {{Dunno}} and {{Unknown}} templates. — Dsimic (talk | contribs) 23:54, 28 May 2015 (UTC)

Since "not applicable" means the cell doesn't apply, I still regard it as a non-answer. The difference between it and {{Dunno}}/{{Unknown}} is that the latter can be answered. However, I don't really care if {{n/a}} uses black text or gray. I feel much more strongly that {{Dunno}} and {{Unknown}} could stand to be merged, grayed out, and made <small>. The appropriate place for such a discussion appears to be Template talk:Table cell templates. I'll let you make the proposals, after which I will vote. It might be wise to reference this discussion in your proposal, so that we disclose our working together and brainstorming beforehand. – voidxor ^{(talk | contrib)} 05:17, 29 May 2015 (UTC)

Speaking about merging {{Dunno}} and {{Unknown}}, a thought about why the merger might not be favorable just crossed my mind: different cell widths. In other words, having two templates that produce "fill me in" cells with labels of completely different widths might actually be good so the narrow one can be used where the space is tight, and the wide (and more descriptive) one where the space isn't an issue; that's somewhat similar to how MOS:DATEFORMAT allows month names to be abbreviated in tables. Also, here are the proposals #5 and #6 above, which show how those two templates look with <small>, and to me they look much better that way.

I had pretty much the same thoughts about starting a discussion on an appropriate template talk page by putting up a few proposals while referencing our work done so far in this discussion. I'll go ahead with that. — Dsimic (talk | contribs) 07:00, 29 May 2015 (UTC)

Just got the discussion started, please see Template talk:Table cell templates § Less busy-looking templates. — Dsimic (talk | contribs) 07:57, 29 May 2015 (UTC)

A side note related to {{Official website}}

I am sorry for the edit conflicts caused. I need to be offline for a while. I'll catch up with the discussion later. -- Magioladitis (talk) 23:50, 31 May 2015 (UTC)

Hello here as well! :) No worries, having a few edit conflicts is perfectly fine and that's always to be expected in an active discussion. See you later. — Dsimic (talk | contribs) 23:55, 31 May 2015 (UTC)

Flexible array member in g++

https://en.wikipedia.org/w/index.php?title=Flexible_array_member&curid=44866380&diff=663078633&oldid=659100780

The value is: it avoids people telling "but it _does_ work in c++!!!" (because their gcc accepts it). Sources? Well, I just found something about "zero length arrays" as a GNU extension for pre-99 C. It does not mention C++ for this feature. :-( --RokerHRO (talk) 15:00, 4 June 2015 (UTC)

Hello! As we know, everything in Wikipedia needs to backed by reliable sources and none of them were provided in this case, which is the reason why I've removed that content from the Flexible array member article. If you could provide sources, which I've been unable to Google out, adding that content back to the article would be more than welcome; otherwise, it's better not to include unsourced information. — Dsimic (talk | contribs) 22:16, 4 June 2015 (UTC)

File:IO stack of the Linux kernel.svg

Hi Dragan, after updating the Linux Storage Stack Diagram, I've found now that you put quite much effort in correcting typos in the former old version of the diagram (I've found the discussion at Wikipedia:Graphics Lab/Illustration workshop/Archive/Apr 2015 § A high-level overview of the Linux kernel's I/O stack). Thank you for your work here! We plan to update the diagram to Kernel 4.0 in the next 2 weeks, I'll include your feedback there. Best regards, Wfischer (talk) 09:06, 8 May 2015 (UTC)

Hello, Werner! You're welcome, and thank you for creating such a great high-level overview in the first place! The least I could do was to improve the diagram's wording, and it would be awesome if you would incorporate all those improvements into the next version. I hope you'll also upload the next version to File:IO stack of the Linux kernel.svg. :) — Dsimic (talk | contribs) 09:41, 8 May 2015 (UTC)

Your're welcome, too ;-) Of course we will include your valuable feedback (I didn't read through all the feedback yet, but will do so when we update the diagram). And yes, we will upload the next version to File:IO stack of the Linux kernel.svg afterwards ;-) Wfischer (talk) 11:38, 8 May 2015 (UTC)

Sounds great, thanks! — Dsimic (talk | contribs) 11:51, 8 May 2015 (UTC)

We have updated the diagram to version 4.0 and updated the SVG File:IO stack of the Linux kernel.svg. I hope we have catched all of your hints. If you have any further feedback, let me just know. Wfischer (talk) 10:49, 8 June 2015 (UTC)

Thank you very much, the diagram looks much better with its slightly cleaner layout and all of the wording cleanups. However, I'd have at least a dozen more suggestions on how to improve the wording, and I'm willing to prepare a complete list if you're willing to incorporate all of them. :) Also, having some kind of a credit on your web page would be nice. — Dsimic (talk | contribs) 21:20, 8 June 2015 (UTC)

Hack (programming language)

Deleting OCaml software category wasn't justified IMO. Look here: https://github.com/facebook/hhvm/tree/master/hphp/hack/src. It's almost entirely written in OCaml and that category is specifically for such cases. 89.42.64.133 (talk) 10:26, 11 June 2015 (UTC)

Hello! As noted in my edit summary, though not clearly enough which I apologize for, Hack isn't something that is "written" using another programming language. As we know, Hack is a programming language specification so its reference implementation, the HipHop Virtual Machine (HHVM), may be added into the Category:OCaml software, which is now the case. In more detail, it's that a few Hack's type-checking utilities bundled together with the HHVM are written in OCaml; see the build instructions and a description of those utilities for further information. Moving forward, I've explained the whole thing further in the HipHop Virtual Machine article. Also, Category:Facebook software doesn't apply to Hack, which I've replaced with Category:Facebook – as a programming language specification, Hack isn't software per se.

Thank you very much for pointing this out, and I hope that you agree. — Dsimic (talk | contribs) 08:09, 12 June 2015 (UTC)

Ok, thanks.

While what you are saying is true - it's somewhat a simplification. When there is only one implementation exists - it is an implementation and the language itself. The specification is tied to the implementation unless it's maintained by some independent body. BTW, HHVM can be used without Hack, but not vice versa. And the only significant novelty of Hack is its' use of types IMHO. 93.117.158.8 (talk) 10:57, 12 June 2015 (UTC)

You're right to a certain degree, but what's written in OCaml are only a few Hack's type-checking (hh_server and hh_client) and code-formatting (hh_format) utilities, which are only helpers and completely non-vital for executing Hack programs inside HHVM. In fact, these utilities don't particiate at all in the execution of Hack programs, they just analyze the source code to help programmers. In other words, Hack's reference implementation works perfectly fine without the helper utilities written in OCaml. Furthermore, HHVM ships together with some Emacs plugins written in a dialect of the Lisp programming language, but those are also non-vital – otherwise, we could also say that small parts of Hack are written in Lisp. — Dsimic (talk | contribs) 18:43, 12 June 2015 (UTC)

I was actually referring to the statement that a specification can't be written in a programming language. The role of OCaml is not important here.

As for importance of the helpers. Well, without them Hack turns from a statically typed language to basically PHP. 89.37.46.114 (talk) 22:06, 12 June 2015 (UTC)

Sorry, I don't get what do you mean by "a specification can't be written in a programming language"? Formally it can't, but the official implementation of a programming language can serve as its specification, that's been the case with PHP for years, for example. Hack's helper utilities should be there to aid programmers, nothing more, while the gradual typing nature of Hack is what's to be implemented within the HHVM. HHVM executes the code, helper utilities merely do preflight checks to make it easier for programmers; if it's instead that HHVM actually ignores the typing information (unfortunately can't verify that at the moment), then it would be a total piece of crap. — Dsimic (talk | contribs) 01:38, 13 June 2015 (UTC)

Here's what the Hack's documentation says on how to go through the process of converting existing PHP code to Hack:

Make as much PHP code visible to the type checker as possible.
Guess type annotations with a global inference tool, but log when they fail instead of failing hard.
Parse error logs and remove annotations that do not match at runtime.
Make the remaining annotations fail hard at runtime.

Here's also a quotation from the same documentation page on how to "harden" type annotations, that is, turn them from @-prefixed warning-generating "soft" parameter or return type annotations into regular annotations that generate recoverable errors:

Once annotations have been added, the logs from the "soft" failures can be automatically parsed to remove the annotations that mismatch at runtime, and to turn the annotations that match into hard failures. Good places to collect such logs include unit test runs and even from production.

With all that and the additional descriptions in the above linked documentation page, it can be confirmed that HHVM does perform type checking at runtime. As a result, type-checking utilities are just helpers non-vital to the actual code execution. They do help a lot, though. :) — Dsimic (talk | contribs) 02:29, 13 June 2015 (UTC)

ShareSpace foundation

Dear Dragan: given my established interest in a re-integration of art and technology, I've started an article on the ShareSpace foundation. Should be interesting to see how it's received.Synchronist (talk) 04:39, 23 May 2015 (UTC)

Hey Glenn! The article looks fine and it's quite interesting, thumbs up for creating it; it's also well-referenced, what's very important. I just did a few small cleaups, hope you're Ok with that. Just as a note, page views statistics for the article are available from stats.grok.se/en/latest90/ShareSpace_foundation, allowing you to see how much traffic the article receives over time. — Dsimic (talk | contribs) 05:03, 23 May 2015 (UTC)

Speaking of which, Dragan, there don't seem to have been any updates on the page view statistics for this article, nor for several others I've checked, since May 23rd (and today being the 31st). I realize that these stats are described as "very much" a beta feature, but can you comment? Or is there somewhere I should have looked first for this internal Wikipedia news? Peace, brother. Synchronist (talk) 22:26, 31 May 2015 (UTC)

You're right, unfortunately there's no page views data on stats.grok.se for the last seven days. Those statistics are unofficial and there's history of data missing for a few days from time to time, which is usually generated retroactively; however, in the last two years or so I haven't seen the data missing for that long, so something strange must be happening. Well, at least it's free so we can't complain too much. :) — Dsimic (talk | contribs) 22:47, 31 May 2015 (UTC)

@Synchronist: Just as a note, stats.grok.se is now back to its fully operational state, working much faster than before. It must have been migrated to more powerful hardware. — Dsimic (talk | contribs) 07:15, 6 June 2015 (UTC)

I did notice, Dragan, and I've been closely following the page view statistics for ShareSpace foundation -- they are quite curious, and, if you have the time, and if it does not seem too politically incorrect, I'd like to know what you make of them. (I have my own theory, but I don't want to bias your interpretation.) Synchronist (talk) 01:25, 12 June 2015 (UTC)

The initial May 23–24 spikes on stats.grok.se/en/latest90/ShareSpace_foundation may freely be attributed to various web crawlers hitting a new Wikipedia article. Later statistics are simply page views, counting how many times the article has been accessed on each day, excluding all of the possibly existing redirects. Some kind of a rule of thumb I'd apply is that halving the daily page views gives the number of different people accessing the article. Of course, I'd really like to hear your theory, if possible. :) — Dsimic (talk | contribs) 06:02, 12 June 2015 (UTC)

Dragan, you may well be right about the bots. My theory focuses on the inner circle of Sharespace and its new affiliate, Destination Imagination: word spread quickly among this inner circle that a Wikipedia article had been started on the foundation; but preoccupied with the mention of Aldrin's environmental apostasy, they did not pass on the word to their thousands of rank-and-file members. BTW, the phrase "On the downside" was that used by Qwertyus to introduce a negative finding to my article on the BLAST protocol. Much more I could say about all of this -- Wikipedia is indeed a fascinating phenomenon! -- but enough for the moment. Synchronist (talk) 23:06, 13 June 2015 (UTC)

Right, it could be very easily an inrush of page visits initiated by the ShareSpace foundation itself – it seems that people like to see somebody else creating a Wikipedia article about something they're or have been working on. :) Another fact supporting your theory is that the initial peak spanned two days, while the crawlers usually get their work done within a few hours. I agree, Wikipedia is almost the eighth wonder of the world, especially because it's a volunteer effort, which might be attributed to the overall positive attitude of the humans as a whole, and the fact that many hands make almost any job easy. :) — Dsimic (talk | contribs) 12:43, 15 June 2015 (UTC)

Your recent additional HDD external links

Hi Dismic: U recently added to the HDD External Links section three articles covering quite low level HDD technical details. There are hundreds of such articles going back many years so I wonder if such detail is appropriate for Wikipedia? If so, where do we stop? Didn't want to just revert without talking - yr call. Tom94022 (talk) 17:34, 6 June 2015 (UTC)

Hello! That's a very good point about the three external links I've added as part of some of my latest edits on the Hard disk drive article. Believe me or not, I had similar thoughts as yours while adding those three entries, and here's what my thoughts looked like:

See, those are rather fine papers describing some of the modern HDD technologies...
... but why don't we have those technologies already described in Wikipedia?
Well, maybe those aren't encyclopedic enough, but hey, they're widely used so even a formal notability check would pass.
However, I'll add links to those papers, they're really nice.
But hey, what it somebody else continues that and adds twenty more of such papers?
Well, if that happens, then we'll trim the Hard disk drive § External links section; until then, it's rather safe and not growing out of control.

Hope you agree. Of course, as always, I'm more than open to discussing this further. — Dsimic (talk | contribs) 22:15, 6 June 2015 (UTC)

Hi! As HDD technologies go these three are really trivial points and the articles cited border on advertisements. Other vendors do or have done the same thing, just different names or not named at all. Furthermore, the three "technologies" linked are far less significant than other HDD technical areas such as, off the top of my head, perpendicular recording, carbon overcoated multilayer sputtered media, negative air pressure heads, thermal flying height control, TMR transducers, sector servos, dual stage actuators, PRML channels, headerless sectors, split sectors, fluid dynamic spindle bearings, dc spindle motors, etc. I could probably find an external article on each and more (some already have Wikipedia articles) but wouldn't that clutter up the article, and probably trim your three links as relatively unimportant. So let's just trim the three now and be done with it. Tom94022 (talk) 06:41, 8 June 2015 (UTC)

Hm, why don't you instead add external links for some or all of the technologies you've listed above (as always, you've provided a rather impressive list)? Providing more information, even only in form of external links, can only add more value to articles. Also, no matter how relatively unimportant RAFF, TLER and PowerChoice may be, those are few of the terms consumers and enthusiasts use a lot, so we should provide at least some coverage of them – if you agree. — Dsimic (talk | contribs) 06:56, 8 June 2015 (UTC)

I have other things to do, but I happened to stumble onto two such articles recently published by HGST so I put them up. IMHO, these two subjects are more notable, that is, far more concern to customers and enthusiasts and far more in common usage than RAFF, TLER and PowerChoice; the latter is a trademark of Seagate and not used much at all other than on Seagate products. Actually now that I think about it, it seems to me that RAFF, TLER and PowerChoice are not notable. The HDD industry participants have been publishing white papers for decades, some now on current webpages but many many more in the internet archive and still relevent but probably not notable. How many external links will it take for us to come to some sort of agreement? Tom94022 (talk) 17:33, 10 June 2015 (UTC)

The two links you've added are perfectly fine, thank you. However, I'm slightly confused why RAFF, TLER and PowerChoice shouldn't be notable? Sure thing, they might not be notable in an academic or professional way, but they're widely used and there are numerous Google hits for them. Moving forward, I've moved the TLER entry to the Error recovery control article, and linked that article in the Hard disk drive § See also section; hopefully, that could be some kind of a compromise. — Dsimic (talk | contribs) 18:21, 10 June 2015 (UTC)

RAFF has little usage outside of WD and descriptions thereof. Technically HDD servo mechanisms have used feed forward for many years to control vibration. Usage of HDDs in RAID cabinets causes somewhat more vibration but so what. This is WD marketing hype of no consequence to the reader of this article.
PowerChoice is a trademarked term of Seagate's and technically should not be used without the TM symbol. Like RAFF it has little usage outside in this case Seagate and describes something that HDDs have been doing for years. This is Seagate marketing hype of no consequence to the reader of this article.

I suppose my fundamental argument against these two is Wikipedia does not promote. — Preceding unsigned comment added by Tom94022 (talk • contribs) 20:48, 15 June 2015 (UTC)

Well, then the mentioning of Helium-filled drives could also be seen as some kind of promotion, as currently only the WD's HGST division produces such devices. Furthermore, they're filled with Helium, "so what"? Why would readers benefit from such Helium-filled knowledge, which may also be seen as some kind of marketing hype? Please don't get me wrong, but the "so what" approach can easily be extended to the point where the whole Hard disk drive article is pretty much irrelevant. What I'd say is that every bit of information counts, even in form of such external links; though, it would be much better to have some prose in the article, for which those external links would be converted into references. — Dsimic (talk | contribs) 08:26, 16 June 2015 (UTC)

Well, I agree Helium is also not notable, just a little bit more notable than the others because it is an Engliish word, not a marketing concoction and there was at least one other prior helium filled drive. I'm happy to delete all three. :-) Tom94022 (talk) 23:50, 18 June 2015 (UTC)

Any chances, please, for you to introduce some prose into the article and use those three links as references? I still think that countering the vibrations (RAFF), power management mechanisms (PowerChoice etc.), and advances in platter counts (Helium) deserve to be covered at least briefly. Having that as part of the article should really help the readers seeking for such information. — Dsimic (talk | contribs) 05:46, 19 June 2015 (UTC)

Welcome to the AfC team!

Hi, and welcome to WikiProject Articles for creation! We are a group of editors who work together on the Articles for creation and Files for upload pages.

A few tips that you might find helpful:

Please take time to fully read the reviewers' instructions before reviewing submissions.
The reviewers' talk page is the best place to ask for help or advice. You might like to watchlist this page, and you are encouraged to take part in any discussion that comes up.
Article submissions that need reviewing can be found in Category:Pending AfC submissions and there is also a useful list which is maintained by a bot.
You might wish to add {{AFC status}} or {{AfC Defcon}} to your userpage, which will alert you to the number of open submissions. There is also a project userbox. If you haven't done so already, please consider adding your name to the list of participants.
Several of our members monitor Wikipedia's help IRC channel, and you are welcome to join in to ask Wikipedia-related questions.
The IRC channel #wikipedia-en-afc ^connect is used occasionally for internal discussion regarding the Articles for Creation process, and also serves as a recent changes feed, displaying all edits made in the Articles for Creation namespace.
The help desk is the place where new editors can ask questions about their submissions. You are welcome to help in answering their questions.

Once again, welcome to the project. Anastasia [Missionedit] (talk) 21:56, 19 June 2015 (UTC)

Your Two's complement edits

Can you read what your placing Not only inaccuracies but anything true stated in devious misleading manner. Did you just copy it from somewhere? If you are not intentionally doing what I have stated above. Slow down and Read what I have summited and see if you really have understood how to state what's going on When represent signed numbers (grade school + or - integers) by what are integers in this S_N_R. Michael Ali theturk (talk) 07:43, 20 June 2015 (UTC)

Hello! Regarding your edits on the Two's complement article, please do realize that they pretty much haven't introduced improvements to the article – just see what the article looks like with your edits in place. See all that broken formatting? Furthermore, could you please, for example, explain why have you removed the tables containing examples of three- and eight-bit integers? — Dsimic (talk | contribs) 07:55, 20 June 2015 (UTC)

(talk page watcher) @Michael Ali theturk: When discussing an articles content, it is generally best to do so on the articles talk page. That way, other interested editors can see the discussion and participate. —Godsy^(TALK_CONT) 07:58, 20 June 2015 (UTC)

Totally agreed. This could be seen as an initial discussion regarding the brief back and forth on a few reverts between Michael Ali theturk, ArnoldReinhold and myself, but further article-related discussion should continue on Talk:Two's complement. — Dsimic (talk | contribs) 08:05, 20 June 2015 (UTC)

Deep learning article

Dragan, the entirety of my contribution to Deep learning was removed two days ago (see https://en.wikipedia.org/wiki/Special:Contributions/99.42.64.25 ), and the only reason I mention it to you is because I'm not sure this action was on the "up and up". But if you don't have the time to take a look, I'll see if maybe QWERTYUS can step in. Ironically, this removal of material linking art and AI comes at a time when there is a huge new burst of interest in the subject; see, for example http://www.theguardian.com/technology/2015/jun/18/google-image-recognition-neural-network-androids-dream-electric-sheep. Synchronist (talk) 03:23, 20 June 2015 (UTC)

Hello! You shouldn't be worried too much about that edit on the Deep learning article, such content deletions happen from time to time. Above all, if that edit were honest and performed by someone really knowledgeable, would he or she use such language for the edit summary? Maybe, but that usually wouldn't be the case. Here's my suggestion how to handle the whole thing:

Restore the deleted content by undoing the edit, describing briefly the reasons in your edit summary.
Start a discussion on the article's talk page, referring to the content removal and describing the used reference, mentioning another source you've linked above (which contains quite amazing and at the same time a tad disturbing depictions, by the way), etc. That way there should be more editors from the field to discuss the whole thing, review the content and possibly improve it, etc.
You may also want to ask one of the administrators (perhaps Acalamari would be willing to have a look) to check whether hiding the slightly offending edit summary would be appropriate, as there's no need for even low-level incivility.

Again, "don't panic", as it stands on the cover a well-known fictious book. :) — Dsimic (talk | contribs) 04:18, 20 June 2015 (UTC)

Done as per your guidelines; can't thank you enough for rescuing my weekend! Synchronist (talk) 03:03, 21 June 2015 (UTC)

You're welcome, and I'm glad it helped. :) If I may provide another suggestion, it would be good to include a link to the article diff you're referring to in the Talk:Deep learning § Art and AI discussion; that way, other editors joining the discussion will know immediately what is it about. You may simply use a complete link to the diff page (such as this one), or even better use the {{Diff}} template to have a link like this one. It is also advisable to always provide brief edit summaries; for example, this edit would benefit from a brief description. Hope you agree. — Dsimic (talk | contribs) 05:11, 21 June 2015 (UTC)

Gotcha in respect to identifying the offending edit on the article talk page; but in respect to the missing edit summary, I was a little afraid of retroactively adding such due to all of the scary warning messages -- it might be like going back in time and stepping on a mushroom! Synchronist (talk) 15:08, 21 June 2015 (UTC)

Furthermore, edit summaries belong to the small "one-off" category of things here at Wikipedia: they can be specified only when an edit is made, can't be added or edited once an edit is saved, and existing ones can only be hidden. Sure thing, edit summaries aren't carved in stone by some magic, :) they're database records as everything else while there are simply no web interface elements allowing their modification. In fact, changeable edit summaries would introduce a rather endless recursion as there should be a revision history for the summaries themselves, and then second-level edit summaries should be provided while editing original edit summaries, etc. :) — Dsimic (talk | contribs) 17:41, 21 June 2015 (UTC)

ECC memory

Hi!

I just read in Wikipedia about ECC memory. Under solutions it lists ECC memory and RAM parity memory. But I find the wording misleading, because the memory itself is not performing the ECC nor the parity algorithm. The memory only offers an extra-wide memory bus (typically 72 instead of 64 bits). The error detection and correction is in all cases a feature of the CPU / the memory controller which creates the parity bits and writes them to the extra-wide memory bus. Upon a READ, the controller receives the data including parity bits, verifies and corrects the data then continues it's processing of that data.

I think it is not clear enough on Wikipedia that ECC/parity are mainly microcontroller-features, just because of the wording "ECC memory", "Parity memory"

But in fact there is now new DRAM-memory on the market with 'on-chip integrated ECC error correction'. See http://www.intelligentmemory.com/ECC-DRAM/ . These ECC DRAMs really perform the complete algorithm inside the memory components on their own. They do not require any special microcontrollers with parity or ECC functionalities, nor an extra wide memory bus is required. Upon a WRITE to the ECC DRAMs, they generate parity-bits and store them separate from the data into an additional memory-area. On a READ, they logic on the ECC DRAMs performs the hamming algorithm and outputs verified&corrected data.

The interesting thing about these ECC DRAMs is that they are 100% compatible to JEDEC standard DRAM components. They can be used in any existing application on the market, no matter if the memory controller is having a 8, 16, 32 or 64 bit bus, and no matter if the controller has own features to handle ECC or parity.

I did not feel comfortable trying to change the Wikipedia entry as my mother-language is not English. Additionally, I work for a company that is distributing the products of Intelligent Memory and I really do not want the Wikipedia page to look like 'advertising'. Still, I am fascinated by the technology and find it worth mentioning. If you would like to work on some changes, I am ready to help and provide lots of input (how about a block diagram explaining the way 'on chip integrated ECC' works?). I am in the memory business since 23 years and can surely support to make some things a bit clearer / more correct.

Regards, Thorsten Wronski t.wronski@memphis.ag 80.156.59.106 (talk) 15:23, 22 December 2014 (UTC)

Hello! Actually, various implementations and their differences are described in more detail in article's ECC memory § Implementations section, which mentions that some implementations depend on the memory controller to do the work, while some other implementations include the ECC logic as part of the ECC memory itself. Of course, the majority of contemporary ECC-enabled systems involve pretty much passive memory devices, at least when looking at the way ECC functionality is handled (buffering usually has nothing to do directly with ECC); an interesting exception is POWER8's Centaur, which puts a lot of logic onto memory modules.

The link you've provided describes a really interesting technology, thank you for pointing it out – I've already included it into the article as a reference. The main benefit and a great thing, as far as I can see, is that it acts as a drop-in replacement for systems not supporting ECC memory in the first place. I'd like to expand its coverage a bit; for example, it would be especially interesting to know how does it interface with the rest of a system that doesn't support ECC memory natively, so the rate/count of detected and corrected memory errors is eventually available to the firmware and operating system? How does it handle uncorrectable errors?

Looking forward to your reply. :) — Dsimic (talk | contribs) 00:23, 23 December 2014 (UTC)

Hi! The ECC DRAM chip does not have a communication-pin for reporting errors, otherwise it wouldn't be a JEDEC-standard-compatible drop-in-replacement to conventional DRAM components any more. But it offers a 'passive' way to read out an error-flag through a special mode register. Unfortunately an error-flag can not tell you when, how often and at which address(es) the error(s) occured. All you get is a flag 0 or 1.

We need to be careful with the definition of 'Uncorrectable errors'. A two or more bit error is uncorrectable by the normal 64/72 hamming code. But a two bit error is at least detectable with ECC algorithms. Now it depends on the exact usage of the hamming code. Most hamming codes can not see a difference between a corrected single bit error and a detected but uncorrected double bit error, same on the ECC DRAM.

Thus, the error-flag could have various meanings:

Error-Flag = 0 -> Either No Error happened or maybe there was a multi-bit error (2+ bits) which was not detectable
Error-Flag = 1 -> Either a Corrected Error occurred or there was an uncorrected, but detected double-bit error

Well, what does this help? In my opionion this does not provide any usuable feedback. We really need to think about the importantce of the ability of detecting - but not correcting - a double-bit error. Some statistics: Let us look at the statistical frequence of double-bit errors compared to a 'complete memory fail' (functional) or 'multi-bit-fail' and you will see what I mean...

Assuming we talk about 1 Gigabit of data which is the typical memory-chip-capacity. That is 1 billion bits. The hamming code is able to correct 1 incorrect bit per every 64 bits. In 1 billion bits there are 16 million blocks of 64 bits. So in theory, a 1 Gigabit ECC DRAM could have 16 million correctable errors at a time without failing, as long as each bit-error is in a different 64 bit word. Or you could say that every 16 millionth bit-error might hit a 64 Bit word where another bit flipped before.

DRAM bit-flips are rare cases. There are several statistics about their frequence, but finally it depends on many hard-to-evaluate factors. But even if we had a bit-flip in 1 Gigabit every day which the ECC DRAM corrects 'on the fly', the probability for an uncorrectable double-bit error in the same 64-bit-word would be 16 Million days = 43800 years. That is 384 Million hours or 3 FIT (failures-in-time).

When you look into a reliability-report of any DRAMs (these documents are available from all DRAM-makers upon request), you will typically see a FIT-value of 11 or higher. Important to know: This FIT-value refers only to total functional fails/defects, and not about the sporadic/random single bit errors. If a DRAM is shown with a FIT of 11, it means it is expected to have 11 defective parts after a billion device hours.

Now what I am trying to say: A 'total fail / defective chip' is about 4 times more likely than having an uncorrectable double-bit-error in an ECC DRAM. I do not dare to specify a FIT-value for single-bit-errors (which an ECC DRAM will correct, but let a conventional DRAM have a real error). The field-study of the University of Toronto named 'DRAM Error in the wild' is talking about 25000 to 70000 FIT of ECC-correctable single-bit errors PER MEGABIT. This would convert to 25 Million to 70 Million FIT per Gigabit. A shocking high number!

Thus I think the importance of ECC focuses on correcting single-bit errors. Everything beyond this requires different methods to secure the continuous operation or safe shut-down of the application.

Additionally, for high-reliability applications it is a good idea to do a 'memory scrubbing' on ECC memory periodically. Scrubbing means that the CPU uses it's idle-time to read from the DRAM and then writes back to the DRAM. This way single bit errors get corrected during the read and that corrected data is then written back to the DRAM. Since the majority of DRAM bit-errors are typically not permanent, scrubbing reduces the probability of 'a second bit-flip in the same 64 Bit word' extremely.

I hope it was correct to 'Edit' the post to add my reply. I could not find a reply button anywhere. Regards, Thorsten 80.156.59.106 (talk) 14:33, 5 January 2015 (UTC)

Thank you for a detailed overview! Though, as far as I can see from it, memory chips with integrated ECC functionality provide a very limited way for reporting their statuses back to the firmware or operating system. As we know, some organizations have policies that mandate replacement of ECC-enabled memory modules once their corrected error counts go over a defined limit, what makes the reporting a necessity. Also, some vendors, such as Apple if I'm not mistaken, even have warranty policies that allow ECC DIMMs to be replaced under warranty if they encounter more than a defined number of correctable errors over a defined period of time.

However, I'd say that the memory chips with integrated ECC functionality aren't even made with the above mentioned applications in mind; instead, they're probably a good fit for embedded systems that have no hardware support for ECC memory – nobody is going to monitor such systems anyway. Though, I wonder how many manufacturers care about not having silent data corruption in CPEs they sell in high volumes?

By the way, clicking "edit" to reply is exactly how Wikipedia works – unlike regular forums, talk pages provide absolutely no functionality specific to posting replies. :) — Dsimic (talk | contribs) 03:38, 6 January 2015 (UTC)

The idea of these products has never been to replace a normal ECC method (through CPU and extra wide memory modules) by using ECC DRAMs. Instead, the idea was to make it possible to have ECC in applications where it was not supported at all before. Look at all the access controls, smart meters, routers, industrial PCs, automotive&avionics electronics, medical instruments, cash-registries and data-entry terminals, ticket machines, any kind of control boards, etc. These are often too small for memory modules with ECC and using ECC-capacble CPUs would also make them much too expensive. With ECC DRAMs they can be upgraded to an extreme stability.

In automotive markets the manufacturers use conventional DRAM, just pretested according to the AEC-Q100 regulations. But this does not protect from single bit errors. You might have seen electronics in your car randomly malfunctioning, but working fine again when you restart the car. No testing can protect from memory errors, only ECC can. And how could anybody use 9 DRAM-chips or a memory module on a little camera module that is integrated into the cars mirror? There is just no space. Automotive manufacturers use multiple methods to at least make sure the applications get safely shut down upon an error, but it is very difficult to control. With ECC DRAM those effects would not even happen (for a 16 million times longer period).

But let me repeat again what I wrote before: A totally defective DRAM is 4 times more likely to happen than an uncorrectable, but detectable double-bit error. And multi-bit (more than 2 bit) errors are not even detectable. Due to this, I see no need for detecting double bit errors.

'Not having any more visible single-bit errors' by using ECC improves the reliability of DRAMs by a factor of 16 Million. Even in the very extreme case of 1 bit-error per day, the DRAM will continue to work flawlessly for many thousands of years (by far longer than it's expected lifetime).

Based on those factors, I do not see a reason why someone would want to get a feedback about corrected single bit errors as long as the system still works. And if the system fails, it was most-likely a total memory-fail, which is 4 times more likely to occur than a double-bit error. Both, the chip fail and double bit errors, will lead to a system-fail as they are uncorrectable and fatal, but fortunately EXTREMELY rare.

I think you are right when you say a memory-module vendor will replace the module when the customer complains about seeing too many correctable errors. And yes, there is this difference from CPU-controlled ECC to DRAM with integrated ECC. The ECC DRAM can not pro-actively inform the CPU about a detected/corrected error. However, it is possible by reading out a flag.

But please do not forget: It is a big milestone to add ECC functionalities at very low cost (no redesign necessary, no expensive CPU needed, no extra memory chips required) to ANY application, no matter what CPU is used, no matter how much space is on the board. Even a $50 WiFi-Router could be made as stable as a server at just a dollar or two more. Any HDD/SSD drive uses 1 DRAM Chip for Cache/Write Buffering and a bit-flip can cause data-corruption (in fact it does happen, I see it on our companies RAID), which would not happen with ECC DRAM.

Technically it would not have been a big issue to add an Error-Pin to the ECC DRAM, but then the big complaint from all customers would be 'it is not compatible, we need to do a re-design to use it'.

The FIT for correctable single-bit errors (according to the field study) might be as high 25 Million to 70 Million FIT (failures in time), while total fails count only 11 FIT and double-bit-errors count only 3 FIT. These numbers show that the key-factor is to eliminate single-bit errors. When these get corrected, the stability is 99.9% secured. 80.156.59.106 (talk) 08:26, 6 January 2015 (UTC)

You're totally right, adding ECC memory functionality to otherwise incapable systems, without the need to modify their designs in any way, is a really, really great thing. However, as I've already noted above, the big question is how many manufacturers are willing to spend those extra few dollars? Please don't get me wrong, I love to see ECC memory in any equipment, but the fact is that profit margins for high-volume products are quite thin.

Asking why would anyone want to have such feedback available is perfectly fine, and one of the reasons is that some companies tend to replace ECC DIMMs once they produce one or more uncorrectable errors. Here's a quote from the Google's DRAM study:

In many production environments, including ours, a single uncorrectable error is considered serious enough to replace the dual in-line memory module (DIMM) that caused it.

Perhaps the feedback for correctable errors might be freely ignored (though, personally, I love to have as much feedback available as possible), but uncorrectable errors should be clearly reported in some way. That's where your error flag comes into action, and it might be even better to see its transition to logical one only if an uncorrectable error is detected. In other words, if its "1" indicates that there are some errors, that isn't too usable, if you agree.

Though, it all depends on where the memory with integrated ECC functionality is used; for example, even if it had full reporting capability, I doubt that car manufacturers would be quickly replacing ECUs with such memory due to a single uncorrectable error. Or maybe they would be replacing them – I can only theorize. :) — Dsimic (talk | contribs) 09:17, 6 January 2015 (UTC)

The field-study is right, an uncorrectable error is serious enough to replace the DIMM. Any yes, it would be nice to see any uncorrectable errors to be reported. Since total DRAM fails are also 'uncorrectable' (as well as 3+ bit error), but are more likely than double bit errors, it would require completely different methods than ECC which can detect ANY error, no matter if the DRAM has a functional fail or multi bit error. ECC can impossibly do that. It would detect only double-bit errors, but before detecting those, 4 chips already had total functional fails or multi-bit errors that were not detectable by ECC! (because of the theory that the FIT-value for total functional fails is 4 times higher than for double-bit-flips)

The capabilities of a standard 64/72 ECC hamming code are limited. If a total fail or multi-bit fail is more likely than a double-bit fail, I do not see a sense in being able to detect only the double bit fails. Either you find a way to catch ALL uncorrectable errors or you accept that there is a very very little risk of failing due to such rare uncorrectable errors. The double bit detection alone is not very helpful. In case of a double bit error, the system will malfunction or crash or perform an automatic reset anyway. And what if it just malfunctions or crashes due to multi-bit or functional fail errors without detection? The information 'system malfunctioned or crashed' is the same.

Until now, all manufacturers use standard DRAMs which do have a bit-flip from time to time. Either they use 9 or 18 Chips per rank in a 72 bit wide memory bus to do ECC by the CPU like on servers, or they have no protection at all.

Automotive applications can not use ECC, they are typically too small to fit so many DRAM chips into them. Any automotive electronics I know is using just one or two DRAMs with a 16 or 32 bit memory-bus to the CPU. There is no ECC. They calculate some of the important data multiple times to compare them and detect an error. This is good, but slow. Additionally the CPU will jump to an interrupt routine when an illegal command is found to be executed. Such illegal commands can happen when there is a bit flip in the program code. You might have seen that when your navigation or multimedia system suddenly resetted itself. Unfortunately not every bit-flip in the program code results in an illegal command, it can also become another legal command causing system malfunction. The possibilities to secure the stable operation of the electronics without ECC are limited. The automotive industry welcomes any improvement, and ECC DRAM will clearly relax and optimize the activity of other functional-safety methods used in the car-electronics. This does not mean they do not need them any more, but the frequence of their activity is getting reduced a lot and they become a lot safer (taking the example of a legal command changing into another legal command that results in malfunction...this won't happen with ECC!).

For consumer electronics and price-sensitivity, I agree with you partially. There are thousands of customers having to reset their electronics periodically. For example just Google for 'Router hang' or 'Router crash' and you know what I mean. It is also a question of marketing and bringing the awareness to the people that they can have something more stable at a few dollars more.

Any manufacturer of practically anything is trying to announce something 'new and better' to the market to present their products being superior. Look at how many new hair-shampoos are fighting each other claiming to have the best results by new ingredients with funny names. ECC in a router or in a HDD/SSD can be promoted a lot better, because ECC is well-known, the people really know the issues and many will happily pay a few dollars more to have a stable product. If each chip costs $1.50 more (for example) and most router just use ONE piece, then the manufacturers cost will increase by $1.50, but he can sell the product to end customers at maybe $5 more. This is not much compared to the massive price difference between electronics without or with ECC. Example: A desktop-PC costs $299, but a server with ECC at least 10 times more. Still the people buy a real server and do not use a standard PC. And if you look at the difference, there is not that much. The main reason for the 'better stability of the server' is in fact the ECC. So in the PC vs Server market the people even realized they have to pay thousands of dollars more to get reliability. Paying $5 more for a router with ECC is peanuts. BUT it requires marketing of these products and then the manufacturer will surely be able to make extra money and gain market share from their competitors.80.156.59.106 (talk) 12:24, 6 January 2015 (UTC)

Well, uncorrectable double-bit errors are rare, and undetectable triple-bit errors are even more rare, but IMHO that doesn't justify a blanket statement that detectable double-bit errors shouldn't be reported at all just because it's more likely that a memory chip is going to fail completely. A total failure of a hardware component in most cases isn't a cause for silent data corruption, and the primary goal of ECC memory is to prevent silent data corruption. Sure thing, it would be great to also cover silent corruption involving more than two bits, but that kind of corruption is predictably very rare.

Regarding the automotive applications and space constraints, I'd say that it also depends on a particular control unit. For example, engine and transmission control units, as well as instrument clusters and GPS navigation units, are usually large enough to house more than a few memory chips, and they're anyway much more important than some random in-car gadgetry. Heck, some GPS navigation units even have built-in 2.5-inch hard disk drives, and those mechanical devices are huge in comparison to a full-size SO-CDIMM, for example. :)

I agree that some marketing around more stable products that contain ECC memory could be a huge selling point, but please let's remember that many of the "reset your router" scenarios are due to software bugs and sloppy firmware and not because of cosmic rays messing up memory cells. :) For example, I used to have ordinary PCs with no ECC memory serving as busy Linux servers, and some of them had 1+ year uptimes with absolutely zero issues (others needed to be rebooted for kernel-related security updates to be applied). — Dsimic (talk | contribs) 18:32, 6 January 2015 (UTC)

Hi! First of all I would like to say: I like this discussion. Thanks for your time for it!

A detected double-bit error still has not been corrected. Very immediate action has to be taken like a Reboot. This is similar to Rebooting on an illegal command, which most CPUs can do. If it is in the data, the data gets lost due to the reboot. But yes, the more reporting you get, the better, I totally agree. I am just trying to show up that having double bit detection is not a major improvement.

I know the memory-demands of Conti, Delphi, Harman, etc. In none of their applications they use ECC and in most they have only one or two DRAMs. There is ONE navigation system using 8 pcs 2Gb DRAMs, so also this is without ECC. I can't say why they did not just put 9 Chips into it. Maybe the CPU does not support it. I talked a lot to people designing driver-assistance systems which are able to keep you on the right lane, detect obstacles on the road, read traffic signs, etc. They told me a lot about the functional-safety methods they currently use and that they only use one or two DRAMs, but they all said they are interested in DRAM with integrated ECC. Some of them had similar questions and concerns as you have, but all agree that having ECC with single-bit correction is MUCH better than using todays conventional DRAMs which have no protection at all.

You could also understand the ECC DRAM as a super-reliable-DRAM, million times better than the hardest tested conventional DRAM, but 100% compatible to a conventional DRAM.

On the router-fails, I do not agree it is software bugs, as a router executes the same (fairly small) software-routines again and again over hours, days and weeks. A PC has much more complex software and a full operating system with many processes running. It depends how you drive the PC. If you run different programs, surf the web, download and install, open/close programs&files, etc, then at some point it becomes slower, eats up your memory or might hang. There sure are some bugs in complex software like Windows, maybe some less on Linux.

If you read the field-study of the University of Toronto, you will find that not every memory module failed! Only 8% of the DIMMs needed to be replaced. Thus some memories seems to work well for a very long time without troubles, while others show more or less bit-flips.

Also, Conclusion 7 of the field study says that the majority of errors are not soft-errors (caused by external disturbance like cosmic rays), but hard errors. Hard Errors are for example 'weak-cells'. They are not permanent in most cases. When a DRAM is intensively used, it will degradate over time and sporadically show a bit-flip. You can see this from the charts in the field study, where the error-rate increases further and further over time. This speaks against cosmic rays, but clearly for a degratation-process. Degradation is a well-known problem of DRAMs. After some time of operation, after soldering processes or even after a longer flight in an airplane, the isolations of the cells get reduced, cell-leakage increases and the data retention-time drops. The cell loses its content before the next refresh cycle sets it back. This appears to be as random as a soft-error, but when watching it carefully, it can be found that always the same cells have this problem, which is a clear sign that it is not caused by an external influence. In many cases the problem only appear with specific data-patterns written to the DRAM, showing that the cells are linked to each other (bit-lines/word-lines, etc) and if one cell gets charged, the neighbor one suddenly also gets part of that charge (due to leakage) changing its binary content resulting in a single-bit-error.

When talking to DRAM test engineers who write the test-programs for wafer-level testing, and for package-level core-, speed- and burn-in-testing, you will always hear that their biggest challenge is to find data-patterns and routines to stress the DRAMs in a way that they show these weaknesses and interferences. During the tests, they always find a handful of single-bit errors which they can repair by e-fusing, but everybody is aware that it is impossible to test in 'every possible way', thus a certain risk for single-bit errors is unavoidable. And unfortunately, those often appear only after some time of operation. The more stress, the faster they appear.

I have a nice report here for a test which was performed on conventional DRAMs. They have been heated up to 85°C, then 95°C, 105°C, 115°C up to 125°C and at the same time the refresh rate was reduced to simulate the degradation. Note: The tested DRAMs were brandnew, never soldered or used, so not degradated. The test was not meant to accelerate degradation (which is difficult anyway), but to show what errors are to be expected IF they degradate.

At the worst case scenario of 125°C and 128ms Refresh-Rate, about 1000 to 8000 bit-flips were observerd in every single test-run on all tested DRAMs. Not even one double-bit error has ever appeared. But at a bit better conditions, some RAMs showed no errors at all, while others had hundreds. This shows that even after the manufacturers testing, there are still DRAMs that are more likely to have issues than others. And it explains that not every DRAM will have errors after some time, but some do, and the percentage is too high to ignore the need for ECC. 80.156.59.106 (talk) 08:16, 7 January 2015 (UTC)

Thank you very much, I also really enjoy our discussion! :)

I agree that having double-bit error detections isn't an improvement by itself, but it allows some kind of damage control, so to speak. In general, such corruptions happen very rarely, but at least someone can know that something went wrong and see what to do about it. Of course, halting or rebooting in case of a detected uncorrectable error might even cause bigger troubles than simply ignoring the corruption – let's just think of complex file systems interrupted in the middle of their busy operation.

Regarding the routers and Wi-Fi access points, many of them actually run Linux, so reduced complexity of their software simply isn't to be counted on. In other words, those boxes are small but quite complex on the inside. :) The main trouble with the stability of embedded systems running Linux comes from the fact that manufacturers usually opt for their own hardware designs with no existing community ports of the Linux kernel; they do the porting themselves, or contract it to someone else, and that results in a much lower quality of the port than what a community-developed port could provide. Why? Because manufacturers have deadlines, tight schedules, not so much enthusiasm, ;) and they end up with a limited amount of testing before releasing a product (when compared to having tens of thousands of people doing the testing in vastly different environments).

Of course, no matter how software/firmware is well-written or not, DRAM bit flips contribute a lot to the overall stability. That's even more important and evident as the amounts of installed RAM increase: not so many years ago, PCs with 128 MB of RAM were common, and nowadays many consumer-level embedded devices have that much RAM. Contemporary PCs went to 8 GB of RAM as standard, the amount of RAM that leads to about one bit flip per week, per field studies. To me, that's a serious thing that turns ECC memory into a necessity.

When looking at a big picture, having no ECC functionality is like gambling – things might work just fine, but not necessarily. Speaking of cosmic rays, I'd say that they serve as a "fallback" description for something we actually don't understand. :) Just as you've described it, many of the bit flips come from undetected manufacturing defects, manufacturing stresses, or simply aging of a device. With ever increasing amounts of RAM per device, and ever increasing complexity of the devices, the issues just grow in size.

What's also really interesting is why consumer-grade PCs still remain without the ECC memory? It's true that profit margins are also quite thin in the PC business, but still, 12–15% more expensive RAM (effectively, if we disregard price inflation due to low volumes) simply doesn't look like a viable explanation for the situation. And, even more interestingly, why there are no laptops with ECC memory? — Dsimic (talk | contribs) 09:20, 7 January 2015 (UTC)

I am still of the opinion that the 'damage control' is not the job of ECC as it's damage-control possibilities are too limited (only double bit error detection). But ECC is fantastic to improve overall reliability, as it is a fact that 99.9% of all DRAM errors are just single-bit-fails.

Really reliable damage control can only be safely achieved by triple-redundant systems. Three CPUs with three separate memories execute the same code and do separate calculations. If one is different from the other two or if one of them hangs, this one must be 'bad'. The method of rebooting upon an illegal program-code only has a small chance to become active, as for example a JUMP-instruction could just be jumping to a wrong address due to a bit error, or the JUMP becomes an ADD command or other legal command. Only if the command-code does not exist, the illegal-command interrupt-routine would help.

On the routers: Maybe they run Linux, but how much of the program-code RAM is being used? Take a PC and only work with one and the same program in the same way for a long time, for example with WORD. The program takes up maybe 2GB of your memory, but if you just type some text, you use by far less than 1% of the total WORD program code. You would not even notice if bit-errors hit into the other 99% of the code. Same thing when using a PC as a server...you only run maybe a few MB of program code again and again, although you have loaded Gigabytes of program-code into the RAM. You also use very very little parts of the total OS. But if you use your PC for lots of things like Excel, Word, Internet, other programs and try all the functions, etc, then your percentage of code-usage becomes a lot larger and the visibility of running into a bit-flip that causes malfunction or crash increases heavily.

Most routers (you can Google for pictures of the PCBs and see it) have just 16MB to 64MB of RAM. I'd say the the code in the RAM is loaded much more effectively than in a PC. Unnecessary routines and OS-parts have been elimiated to make the code fit into the small memory. However, routers also have lots of menus, features and settings. During normal operation of the router the effectively used code for just transferring data in and out to/from the web is again just a small portion of something between 1% and 5%.

With 1% effective RAM usage, only every 100th bit-flip causes visible trouble. I have three (different) routers at home, two used as repeaters. Two of the routers need a Reset about every 3 months, although I do regular software updates. And interesting enough the errors on both are different every time. Sometimes it does not accept my WiFi password and asks me to re-enter (which does not help=, sometimes it just does not connect although every entry in the menus looks fine, next time one of the submenus does not appear, another time I can not connect to it through it's IP at all, although it still lets me into the internet, etc etc. It is really weird! When I googled if other people have similar experiences, I noticed that the web is full with millions of entries about router hangs and random functional fails for all brands of routers. So it is not limited to one router with one specific software.

One day I opened the routers and noticed the antenna cables are lose-wired going right over the DRAM....I assume here we really can talk about soft-errors!

The same problem happens on HDD/SSD drives. There is just a 512Mbit (64MB) DRAM on it which is mainly used for Cache&Write Buffering as well as for running the (very small) firmware. The SMART features of the firmware add a cyclic CRC checksum to the data (only the data, not the firmware) passing through the RAM and in the SMART-value IOEDC End-To-End Error you can then retrieve the count of errors. An error hitting the data in the cache will increase the number of those End-To-End errors without repairing them (file on drive damaged), but a hit into the firmware can cause worse malfunctions. And in fact, I sometimes experience that I save a file to the drive and when trying to load it again it says the file is corrupted. This even happens on our big company raid-system. If it was a bit-error on the magnetic media, the drive normally tries to read multiple times before it reports an error. And re-trying then sometimes helps. But what I experience when I have a bad file is an immediate 'file corrupted' error that can not be corrected by re-trying. Thus I think the write-buffer (DRAM) had a bit-flip when writing the file to the drive and the data got incorrectly written to the media. Well, I don't really know, I just guess. But I am still very sure that many business customers would pay $5 more for Enterprise-HDD drives having ECC on the DRAM. And the HDD manufacturer could also 'proudly present his new innovation' and take away market-shares from their competitors, publish press-releases, get magazines to review it, etc. If the manufacturers like, they can also offer their drives with and without ECC DRAM at two different prices. In this case the customers will question the difference, read into it and then decide 'do I want the increased safety or not?'. Many will!

Do you know the "Intel Inside" sticker on many computers? There is an "I'M ECC PROTECTED" sticker/badge/logo which Intelligent Memory offers to customers using their DRAMs. I think it is a good marketing tool to put onto the end-products, product websites, brochures, advertisings, etc to show the end-customers what they get for the extra-money! If I could have your e-mail address, I can e-mail you some things. I do not want to type mine here, but if you e-mail to sales@memphis.ag and put into the subject 'Att. Thorsten', I will get it and reply to you. 80.156.59.106 (talk) 10:31, 7 January 2015 (UTC)

Sorry, perhaps I haven't expressed myself clearly enough when referring to "damage control"; what I also wanted to say is that ECC's protection against silent DRAM corruption (that is, one-bit errors) is the best kind of damage control it provides. Handling of uncorrectable double-bit errors is just a continuation of that.

As you've described it, usage of RAM contributes largely to how a computer is going to react to a silent DRAM corruption. Speaking of Linux running on embedded systems, it's true that Wi-Fi APs or routers don't use a lot of RAM, but NAS appliances, as another example, use everything that's available for caching and various file system-related operations. Having a flipped bit in NAS appliances is even more dangerous, as that has the potential to cause file system corruption and loss of user data. Sure thing, the amount of RAM in embedded devices depends on what they're used for, so a Wi-Fi AP might run Linux just fine with as low as 16 MB of RAM, while a NAS appliance needs more RAM (they usually have around 256 MB).

As far as I know, end-to-end data protection doesn't exist in consumer-grade SATA HDDs; that's reserved for the enterprise segment and SAS HDDs. That's the reason why there are advanced file systems, such as Btrfs and ZFS, which implement end-to-end data protection on their own, by calculating and storing checkums of data and metadata. However, file corruption issues you've experienced sound quite uncommon to me – are you sure that the hardware you're using isn't flaky? I've seen such random corruption only on some flaky hardware. For other issues related to HDDs, you might want to have a look at unrecoverable read errors; back at the time I've compiled a good summary there. — Dsimic (talk | contribs) 11:16, 7 January 2015 (UTC)

Well, a single bit flip here and there is not a sign of a damaged DRAM for me. It just happens, either due to external disturbance or a cell weakness which only shows up with certain patterns of data. To a normal DRAM without ECC it is an 'effect', not a 'defect', but still the effect can cause a damage. However, such effect can typically not be repaired by replacing the RAM, as the next RAM will most-likely also see such effect every now and then.

As my point of view is 'single bit errors happen, they are not a sign of defect, we can't avoid them', I see ECC being mandatory for system stability, but it is nothing I need to count to evaluate if the DRAM is bad. DRAMs just tend to have those hiccups, we just need ECC to cover them, but - depending on the safety level required - we can hardly evaluate the system-stability by getting informed when they happen. If someone puts his cellphone on the electronic device, there might suddenly be an increased number of bit-flips in the device. As soon as he takes it away, the issues are gone. Is this already a sign for a DRAM of the device being bad? I think the DRAM has just gotten into a temporary critical environment. Same in a car... park the car in the sun, the inside mirror gets over 100 degrees hot, the DRAM in the camera or distance-sensor gets some bit errors. But when it cools down, it is fine again. The DRAM is not damaged, but it was under temporary stress and ECC can save it! And again the same under radiation, high data-traffic between DRAM&CPU, etc.

The risk of 'errors adding up to result in an uncorrectable double bit error' is extremely little and can be avoided by scrubbing during CPU Idle-Time.

Yes, especially Enterprise drives have the SMART features. Here in the company we use only Enterprise class SCSI drives, where the price is 5 times higher than for a consumer drive. Our employees save and open hundreds to thousands of files every day. It does not happen very often, but it does happen that files become unreadable for unknown reason. We can read out the SMART parameters of the drives and can see some IOEDC (Input-Ouput Error DETECTION Code) end to end errors occured, but have no information on when they happened nor which file is affected, so I can only guess there is a relation to those files which we found becoming corrupted. Per the WikiPedia documentation of the SMART parameter for IOEDC : 'This attribute is a part of Hewlett-Packard's SMART IV technology, as well as part of other vendors' IO Error Detection and Correction schemas, and it contains a count of parity errors which occur in the data path to the media via the drive's cache RAM. 80.156.59.106 (talk) 11:50, 7 January 2015 (UTC)

Totally agreed, as the purpose of ECC memory is to recover from singe-bit errors. If having single-bit errors from time to time would be seen as a sign of bad DRAM, that would mean it is possible to manufacture perfect DRAM that would never ever encounter bit flips – and as we know, that's pretty much impossible.

Everything shows that ECC DRAM is they way to go, either through native hardware support or by using DRAM chips with integrated ECC functionality. Hopefully more equipment manufacturers will share the same point of view. :) Do you, maybe, have any insights why there aren't any laptops with ECC memory? That's very strange, and I'd be extremely happy to pay even a significant price premium for such a laptop.

The silent (or not so silent) corruption you're experiencing in data storage is really interesting. Does the manufacturer of storage system you're using have anything to say? I wonder how would Btrfs or ZFS perform in such an environment... Is the overall storage capacity and number of HDDs something you'd be comfortable with sharing here? — Dsimic (talk | contribs) 07:44, 8 January 2015 (UTC)

The right people at the manufaturers of storage systems are difficult to find. They have an endless number of employees. I was hoping that a bit more detail could appear on Wikipedia about the ECC DRAM technology, so more potential customers find it and more 'awareness' is being created. If you have any further ideas on that, I would really appreciate any kind of activity that helps making the world aware of this technology. I think it really fits to each and every industrial, automotive, medical, military product, no matter if the application is computing, networking, telecommunication, storage, control, measurement, etc, because all of these applications require to be 'better than a normal PC' and should run perfectly smoothly without ever requiring to be rebooted/resetted.

Laptops with ECC are really rare. Only some rugged military laptops might have it. BUT: With 16 Chips 1Gbit ECC DRAMs we can build 2GB SO-DIMM modules, where each chip has ECC. Since 8 chips are per memory-bank, you get eight times ECC in parallel! This is a lot stronger than having a 72 bit bus with just one time ECC over all bits. If 2GB modules are big enough for you, then we can do that. 80.156.59.106 (talk) 11:47, 8 January 2015 (UTC)

You're right, reaching engineering people is almost an impossible mission in larger companies. Could you, please, send me a few links to data sheets for the DRAM chips with integrated ECC functionality, their specifications, related promotional materials, etc.? Of course, all that needs to be publicly accessible so it can serve as references. After reviewing all that, I'll see how to add more content into already existing articles – you're right that such a technology deserves better coverage.

As you've pointed it out, such SO-DIMMs would be even better than regular SO-CDIMMs by offering "finer grained" ECC protection. Does your company already sell such DDR3 SO-DIMM modules in small quantities? If so, what are the prices compared to same-capacity standard non-ECC SO-DIMMs? Also, I was wondering whether your company sells small/sample quantities of DRAM chips? I have a few embedded Linux devices (Wi-Fi access points, small NAS appliances, etc.) that would benefit from replacing their factory-soldered "plain" DRAM chips. — Dsimic (talk | contribs) 22:06, 8 January 2015 (UTC)

Hi Dragan! FYI, a lot of the info and datasheets you ask for is visible and downloadable at www.intelligentmemory.com and on the FAQ pages, etc, but I have even more documents I can send. But how can I send you that? I can hardly include it here onto the talk-page.

And yes, we do build such modules and can also make them based on ECC DRAMs. I can tell you pricing by email, but I do not have your email address! 80.156.59.106 (talk) 07:56, 9 January 2015 (UTC)

Please let me dig through the documentation available on intelligentmemory.com in the next few days, and I'll let you know if more would be required. Basically, all that would be used as references needs to be publicly accessible on some web server; I could host some files for you, but it would be much better if you could host them somehow on your company's website (perhaps you have some means to make more files downloadable through the CMS you're using, or maybe by uploading them manually).

The availability of such SO-DIMM modules is a great thing, thank you! What about individual DRAM chips in small/sample quantities, for replacing DRAM chips soldered in embedded devices such as Wi-Fi access points? Sure thing, I'd provide specs of the currently soldered DRAM chips. I'll shoot you an email to t.wronski@memphis.ag in the next few days, or you could open an account here on Wikipedia and use the "Email this user" functionality that's available on this page for registered users. — Dsimic (talk | contribs) 22:25, 9 January 2015 (UTC)

Individual DRAM chips in small/sample quantities are also readily available in stock. Just let me know what you need. I hope you have a BGA soldering station to replace the parts. After replacing the RAM, try and heat up the ECC DRAM or disturb it with an antenna or in any other way. You will see that you can't get it to fail unless you use brute force.

I don't think I need a Wikipedia account. If required, I can put any additional documents into Dropbox or something like that. — Preceding unsigned comment added by 80.156.59.106 (talk) 12:50, 13 January 2015 (UTC)

That's awesome, and I was hoping to be able to outsource BGA soldering to some local shops; of course, I need to verify first whether that kind of work is actually doable locally. By the way, I already went through one part of the documentation available on intelligentmemory.com and will come back soon with an update. — Dsimic (talk | contribs) 01:28, 14 January 2015 (UTC)

Some new links:

http://embedded-computing.com/guest-blogs/why-ecc-matters-in-embedded-design/

http://www.electronics-eetimes.com/en/dram-chips-integrate-error-correcting-code.html?cmp_id=7&news_id=222922892#

And did you read the product-brief? Here is the link:

http://www.intelligentmemory.com/fileadmin/download/PB_IM_ECC_DRAM.pdf

80.156.59.106 (talk) 08:37, 15 January 2015 (UTC)

Thanks, those are good links, and I haven't read this product brief before. I've also considered whether Intelligent Memory would be notable enough for a separate article; please see WP:NOTE for Wikipedia's notability requirements. Unfortunately, running a Google search doesn't yield a large coverage in form of potential reliable sources, some of which are these:

http://embedded-computing.com/news/intelligent-code-ecc-functionality/ (pretty much the same as one of the links you've provided, but not presented as a blog entry)
http://www.anandtech.com/show/7742/im-intelligent-memory-to-release-16gb-unregistered-ddr3-modules
http://www.tweaktown.com/reviews/6817/i-m-intelligent-memory-16gb-ddr3-udimm-memory-review/index.html
http://www.guru3d.com/news-story/im-intelligent-memory-8-gigabit-ddr3-and-16-gb-modules.html

Are there any other secondary sources, third-party reviews, etc. available, which a Google search was unable to find? Having only a few more would be just fine. — Dsimic (talk | contribs) 09:09, 15 January 2015 (UTC)

It seems you found several older press-releases about the world's first 8 Gigabit DDR3 chips which were designed by Intelligent Memory. These chips make it possible to build unbuffered DIMMs and SO-DIMMs up to 16 Gigabyte, while ALL other manufacturers only have such modules up to 8 Gigabyte, because they only have maximum 4 Gigabit DDR3 components. Intelligent Memory uses their own (patent pending) method to make 8 Gigabit chips without having to wait for new manufacturing-technologies like 25nm. A 25nm DRAM manufacturing process would allow to put 8 Gigabit of memory onto a single die, but such processes cost billions of dollars and are about to go into mass production only by this year. Intelligent Memory thought "why wait? why spend so much money?" and invented a very unique method to use two conventional and readilty available 4Gb dies made in 30m process, interconnect them in a really tricky&specific way and put them into one chip-package. The fnal product looks/acts/works as if it was a monolithic 8 Gigabit chip. The very first samples were made in 2013, which is 2 years earlier than the big memory-manufacturers are able to release their 8 Gigabit memories in 25nm.

And even more interesting: As soon as the big manufacturers have 25nm monolithic 8 Gigabit DRAM components (for example in DDR4), Intelligent Memory can take their technology to make 16 Gigabit chips from these! It would take at least another 5 years before other manufacturers can do the same by another process shrink as they would require processes smaller than 20nm to put 16 Gigabit onto a monolithic chip.

While this technology of IM is also very interesting, it it not related to the topic of "ECC logic integrated into the DRAM" which we are dicussing here.

The ECC DRAMs have been officially published and released on the Memphis booth at the Electronica show in November this year. News release: http://www.memphis.ag/fileadmin/newsroom/newsletter/Archiv/2014/Memphis_1410.html

Also please take a look into this folder please: http://www.intelligentmemory.com/download/

And I would like to refer to the FAQs where you find many questions/answers about ECC DRAMs: http://www.intelligentmemory.com/faq/

I posted a comment about ECC DRAM on this page: http://thememoryguy.com/memory-issues-in-space-medical-applications/

Another forum posting:http://www.tomshardware.co.uk/forum/id-2472284/hdds-ssds-issues.html

But I know, there is a LOT more activity to be done to create an awareness for the ECC DRAM product series, for the simplicity of upgrading 'anything' to have ECC, but also for the 'need to have ECC' especially on all the industrial applications or anything that should run 24/7 like routers, HDDs, SSDs, access controls, Smart-Meters, POS systems, industrial controls, surveillance cameras, ATM machines, robot-controls, traffic-systems, networking devices, automation-systems, medical, military, automotive, etc.

When you look at any electronics device, even those of which the manufacturers say they would be industrial, rugged, robust, high quality, reliable, stable, etc, you will rarely find ECC being used. The only exception is Servers, where people pay 10-20 times the price of a PC.

Talking to the manufacturers of such products on the one hand creates a certain interest, but they do not even want to pay $1 more as they think they can't get that money back when selling and they would not be competetive any more.

I am not expecting that a manufacturer of a settop box or tablet-PC wants ECC, but I am convinced that all those above mentioned electronics should at least match the quality of a server. The customers buy those products and pay a high price because they trust in their reliability, which can impossibly be guaranteed without ECC.

If a manufacturer of such devices tells me 'we have no problems reported by customers and get no returns', I say 'Do you return your PC or Smartphone when it crashes and works again after a Reset?'. The big misunderstanding is that bit-flips are not permanent defects leading to an RMA, but they are randomly appearing and non-repeatable effects which customers do not want to have when buying a professional industrial electronics device.

I am 100% convinced that the end-customers select the product they buy not only by price, but by reputation of the manufacturers brand/products for reliability, features, functions.

If the manufactures add the ECC functionality for their products and promote it to the world, do press releases, point out the reliability features on the website and brochures, maybe let magazines review the product, then this manufacturer will become a market&technology leader. Customers buying such products will have to decide if they buy from company A) at lower price without ECC or from company B) with the 'server grade reliability by ECC' at a very little higher price. I am also sure that the expression 'ECC' is familiar to everybody buying electronics, but electronic-magazines can also be pushed to write more articles about its importance.

Well, there is a lot to do to change the thinking. 80.156.59.106 (talk) 10:56, 15 January 2015 (UTC)

Sure thing, I didn't mean to imply that integrated ECC and higher-density DRAM chips are directly related, but if Intelligent Memory would be created as a separate article, all aspects and products would have to be described there.

Speaking of references for the separate article, this one would be good as it isn't a primary source; roughly speaking, all content residing on a manufacturer's website is considered as primary sources. In a few words, articles need secondary sources as that's how Wikipedia works; please see WP:USEPRIMARY for more information. Also, forum posts unfortunately can't be used as references.

Please don't get me wrong, but I've been convinced that ECC memory is the way to go long, long time ago. :) That's why I'm now considering the creation of a separate Intelligent Memory article, which might help in increasing the overall awareness of the necessity for ECC memory. And for that article, we'd need a few more secondary sources that describe integrated-ECC DRAM as one of the IM's products. — Dsimic (talk | contribs) 11:41, 15 January 2015 (UTC)

Yes, we need more people to talk about it, then there will be more secondary sources talking about it. All I can do is post into forums. To make others talk about the product and to write articles, it requires awareness of the product. Hen and egg problem. A really good article is this one that I just commented on http://www.zdnet.com/article/flipping-dram-bits-maliciously/#comments. 80.156.59.106 (talk) 12:28, 15 January 2015 (UTC)

You're right, that one is a very good article. Speaking of secondary sources for IM's integrated-ECC products, may I suggest that you donate a few sets of integrated-ECC DIMMs and SO-DIMMs to the guys over there at phoronix.com? I'm sure they'll be more than happy to write a good article on their website, which is highly respected. Moreover, I'm sure they would use and mention those memory modules while creating more than a few articles later, for example when they test new models of motherboards or laptops so compatibility and performance can be assured. — Dsimic (talk | contribs) 12:39, 15 January 2015 (UTC)

Just to make it clear, I have absolutely no affiliation with phoronix.com. — Dsimic (talk | contribs) 12:56, 15 January 2015 (UTC)

I don't mind sending out samples to them, but Phoronix is very much related to standard comsumer PC hardware, while the ECC DRAM makes most sense in the area of industrial, military, medical, automotive, avionics, networking and other electronic devices which use DRAM chips rather than modules. However, anything that helps creating an awareness will be fully supported by me. Do you know the people there and can brief them a bit and then ask them to contact me? Otherwise it becomes a 'blind call' which is less effective.

And if you have ideas for industrial markets, let me know as well. I like the Wikipedia idea generally, but it has to be carefully created in a way that 1) people searching for ECC technologies find it and 2) it does not appear as a promotion.

It could fit well as a new point 5.14 at http://en.wikipedia.org/wiki/Dynamic_random-access_memory and also mentioned in point 6 of the same entry. What do you think?

And it could fit into http://en.wikipedia.org/wiki/Hamming_code under point 5 ("see also") and point 7 (references). Maybe even a point "implementations" could be added referring to integrated ECC on DRAM by Intelligent Memory as well as to integrated ECC on SRAM memory by Cypress (they have done it for some of their SRAMs. Let me know if you need the link)

Do you dare to add/modify these Wikipedia entries? 80.156.59.106 (talk) 13:11, 15 January 2015 (UTC)

You're right that Phoronix primarily deals with consumer-grade hardware, but many people who read their articles also work or deal with embedded devices. That way, starting the "buzz" in the consumer market should have a potential for spreading it much further. Also, I'd bet that many people want ECC memory for their laptops, but they have no idea that IM has a very good solution in that field; that's where Phoronix would fit the bill extremely well.

Or, maybe you could buy a few popular Wi-Fi-enabled embedded devices that run Linux, replace their DRAM chips with IM's integrated-ECC chips, and send them off to Phoronix for a long-term reliability testing. Or, even better, send a few dozens of such modified embedded devices (possibly not all of the same device type) off to the developers at openwrt.org for another round of long-term reliability testing. Over time, that should almost surely create a snowball effect.

I don't know the Phoronix or OpenWrt people, but I would be wiling to contact them – effectively being the one who makes blind calls and does the preparation for you. :) I'd also ask them which exact embedded devices or memory modules they would prefer to receive, so we make the whole thing as effective and productive as possible. Would you find something like that acceptable?

Also, I hope that you might be willing to donate another few ECC-modified embedded devices to random Linux kernel developers that seek for them for various development purposes. They all perform reliability testing as well, and all "buzzing" should sum up over time. Unfortunately, I can't make a list of such developers right off the bat, but I stumble upon them from time to time; I'd also be willing to contact them and do the briefing/preparation – if you'd find something like that acceptable, of course.

Speaking about expanding those Wikipedia articles – sure thing, I'm willing to do that, but IMHO it would be much better to create Intelligent Memory as a separate article first and link it from other articles (with brief context-supporting summaries, of course). That way, information wouldn't be duplicated around, and there would be a central place in which interested readers would be able to find a much better overview than it would be possible by just expanding other articles. Of course, nothing is allowed to look or sound like an advertisement, simply because that isn't the spirit of Wikipedia; also, that's strictly forbidden by the WP:NOTADVERTISING guideline. — Dsimic (talk | contribs) 14:30, 15 January 2015 (UTC)

Replacing chips on WiFi Routers is not easy. It requires BGA soldering systems for that. It would then require to accelerate the bit-flips by radiation, heat or other disturbances. Not easy.

Whenever Phoronix, OpenWrt or any others are interested to test the components or modules, I will be ready to sample. Eventually it will be done by 'loan' or if the value is not too high it will be just free samples. So please feel free to get in touch with some people or companies.

Electronics magazines are also a good place, but they can just report, not test. Companies making routers, smart-meters or other electronics are very good targets, but they will not write reviews.

That said, I am still thinking that the two WikiPedia entries I mentioned in my last message are a perfect place for the information in a brief way, but having it visible to a lot of people. The seperate Intelligent Memory page can be set up later, when there are more resources. 80.156.59.106 (talk) 07:31, 16 January 2015 (UTC)

You're right that BGA (re)soldering is time-consuming and complicated. However, I don't see an easier way to give people some embedded devices they can use to test things out, and write or talk about them later. That said, an investment into BGA soldering equipment, or the cost to outsorce it to somebody else, could be seen as an investment into advertising – and, from my experience, effective advertising never comes cheap. :)

Accelerating the bit flips might not be necessary, as the whole world of Wi-Fi access points is full of "misterious" lockups and misbehavior, which I've also seen myself countless times. Some of them are surely due to software bugs, but the majority has to do something with the close proximity between DRAM chips, radio interfaces and various pigtails hanging over the PCBs. Anybody who regularly deals with Wi-Fi access points should be able to easily see the difference in reliability after some time; it would be some kind of a real-world field study, but that's what counts most in the end – if you agree.

At the same time, outdoor Wi-Fi access points are often mounted inside poorly ventilated enclosures, which in summer time create a much better environment for bit flips. :) All that makes it somewhat easier for people to "sense" a real-world level of reliabilty improvements.

I know, giving things away might look ineffective, but that's how really big things became what they currently are. OpenWrt is a good example of such a project – it started small, but millions of people now use it or know what it is. Another example is the well-known Linksys WRT54 Wi-Fi device, which OpenWrt initially was made for: back at the time, Linksys was the only manfacturer to make the firmware source code easily accessible and in a complete form, effectively giving it away, and that snowballed making the WRT54 a legendary device that sold in who knows how large quantities.

Please don't get me wrong, I'm not trying to convince you in any way; instead, I'm just providing some examples that might be related. :)

Went ahead and expanded and clarified the Dynamic random-access memory article a bit; that's as much as can be added there without going against the WP:NOTADVERTISING guideline. Also, integrated-ECC DRAM wouldn't fit into the Dynamic random-access memory § Security section as it describes data remanence, which ECC has pretty much little to do with (maybe some more data could be extracted from powered-off DRAM by reconstructing it from extra bits, but that would require a strong reference anyway).

Speaking of the Hamming code article, it describes the algorithm background while mentioning with very little of the actual products that use it; thus, adding product-related links as references unfortunately wouldn't make much sense. Also, "See also" sections can contain only links to already existing articles; once created, Intelligent Memory article might be added there. — Dsimic (talk | contribs) 10:16, 16 January 2015 (UTC)

I highly appreciate all your input. And yes, I know a company having BGA soldering machines that could replace the RAM and I have no issues to do that for anybody that sends me a product to perform the testing and write about it on the web afterwards. But I can not buy routers or other products to rework them. If somebody wants to send us a router or other product to get it modified, I can arrange that.

Especially if someone has such a Linksys WRT54 with known issues! Just buying a brandnew one can result in 'no issues at all even without ECC', because #1 not all DRAMs show up bit-flips, #2 most bit-flips only appear after some time of use, months, years or decades, #3 it is best to have a product that has known issues, although others have the same product with no such issues. If the problem-product gets fixed by ECC DRAM, we have even stronger proof! 80.156.59.106 (talk) 10:31, 16 January 2015 (UTC)

Thank you, I also highly value our discussion. :) That's a very good point: replacing DRAM chips in an embedded device that's known to malfunction would be the best option! I'll see what can be done – finding people with such "bad" devices shouldn't be that hard. :) Of course, it would be necessary for the testing afterward to be publicly documented. — Dsimic (talk | contribs) 10:42, 16 January 2015 (UTC)

I just found another article and had to post my comment to it right away ;-) http://smallformfactors.opensystemsmedia.com/articles/ruggedizing-ram-industrial-systems/ 80.156.59.106 (talk) 10:43, 16 January 2015 (UTC)

Ah, they use mezzanine-style connectors to improve mechanical and electrical reliability, but with optional ECC. :) — Dsimic (talk | contribs) 10:53, 16 January 2015 (UTC)

Did you also see my comment to it?

FYI, the Linksys WRT54 seems to be quite old. It uses a 128Mbit DDR1 Hynix HY5DU281622FTP-J chip (very old and end of life). Today the DDR1 technology is rarely used and capacities are normally 512Mbit. I can hardly replace a 128Mbit with a 512Mbit, that might not work. Picture: http://dicks.home.xs4all.nl/wrt54gl-1.jpg 80.156.59.106 (talk) 10:58, 16 January 2015 (UTC)

Sure thing, I saw and read it; just wanted to say how irrational sounds to invest so much effort and funds into a brand new reliability-oriented memory module form factor without making ECC one of its mandatory features.

You're right, WRT54 is an old design but still quite popular; though, due to its age we'll seemingly need to cross it off the list of potential candidates for "transplantation". How about some of the RouterBOARD embedded devices instead, they're also quite popular? For example, RB411, RB411AR, RB433AH, RB450, RB450G or RB493G models – are their memory chips available in integrated-ECC variants? It might be that even RouterBOARD as a manufacturer could be interested in using integrated-ECC DRAM chips, as they need reliability and RouterBOARDs are sold in really huge quantities, both as indoor/outdoor access points and CPEs. — Dsimic (talk | contribs) 11:14, 16 January 2015 (UTC)

Hm, all of them must be over 5-10 years old. RB411 (DDR1 256Mb TSOP), RB411AR (DDR1 512Mb TSOP), RB433AH (DDR1 512Mb TSOP), RB450 (DDR1 256Mb TSOP), RB450G (DDR1 256Mb TSOP), RB493G (DDR1 512Mb TSOP). In DDR1 I have only 1 Gigabit in TSOP and 512 Megabit in BGA.

I also looked at newer models like RB951G (DDR2 512Mb BGA), RB2011UIAS (DDR2 512Mb BGA). For these I have the right parts in stock

The company behind Routerboard is Mikrotik. They are EXTREMELY price sensitive, which you can also see by the low sales prices they have for their routers!

Their higher end routers use cheap Kingston memory modules (SO-DIMMs) without ECC. I could not find any outdoor product. 80.156.59.106 (talk) 11:39, 16 January 2015 (UTC)

Those RouterBOARD models are relatively old; for example, RB450G was made available in February 2009, while RB493G was made available in November 2010. Well, at least it would be far easier to replace their TSOP-packaged DRAM chips, if their integrated-ECC variants were available. :) However, that's what RouterBOARD sells, and people buy a lot of them.

You're right that RouterBOARD/MikroTik is price-sensitive, but those prices listed on routerboard.com in most cases aren't retail prices; for example, RB493G is listed with $199 as its MSRP, while its retail prices in Europe can be as high as 220 euros. To me, as well as to the majority of consumers, that price in euros is quite high for an embedded system with a 680 MHz CPU, 256 MB of RAM and 128 MB of flash. At the same time, they might want to shave $1–2 off their per-unit profits just to have "rock solid with ECC" as a selling point for their products: when such a board has 20–30 Wi-Fi customers associated on it, people usually want reliability. :)

Regarding the outdoor products, well, all those models are also used that way. :) People just put those boards into outdoor boxes and that's it. There are some dedicated outdoor models, such as NetMetal 5, NetBox 5 or Groove 52HPn, but they're pretty much the same thing packaged in an outdoor box by the manufacturer. — Dsimic (talk | contribs) 12:20, 16 January 2015 (UTC)

Well, if there is someone having any of those boards with random and 'always different' kinds of fails, and that board uses a 512Mbit TSOP, then I could put a 1 Gigabit TSOP on there and manually wire the address line A13 to ground. The chip will then behave like a 512 Megabit Chip.

But for D-Link, Linksys, Netgear, Huawei, AVM and other routers, I see much more models using DDR2 or DDR3 memory. I can usually easily identify the DRAM by look at the PCB. And there are LOTS of pictures of opened routers on the web, so I can practically find out the DRAM-type on every router.

Try to google for 'router sometimes stops working' or other word combinations. MILLIONS of entries! 80.156.59.106 (talk) 12:49, 16 January 2015 (UTC)

I'll try to find some "flaky" candidates for the "transplantation" of DRAM chips. You're right, there are countless other models of Wi-Fi access points / routers, and none of them is free of lockups and misbehavior; in other words, that's a huge market for ECC memory, with potentially huge benefits for the mankind. But, how to convince people that ECC memory is beneficial, that's the hard thing... :) That's why I've suggested all those steps for increasing the level of public awareness. — Dsimic (talk | contribs) 13:38, 16 January 2015 (UTC)

Read this (and my reply): https://forum.openwrt.org/viewtopic.php?pid=261711#p261711

This guy uses a TPLINK router and I can upgrade that! 80.156.59.106 (talk) 14:39, 16 January 2015 (UTC)

Nice catch, that looks like a good candidate; let's see what will the original poster reply. — Dsimic (talk | contribs) 18:17, 16 January 2015 (UTC)

No reply, yet. Maybe you can post a reply to animate the users to get some discussion going? 80.156.59.106 (talk) 11:33, 19 January 2015 (UTC)

As we know, sometimes it takes more than a few days for people to respond. Providing some replies from my side in that forum thread would hardly be helpful, :) as I already know about the whole thing; to get it going, we need involvement and comments from actual people seeking for help or advice with their misbehaving embedded devices. — Dsimic (talk | contribs) 08:18, 20 January 2015 (UTC)

Just saw your forum post, but for some reason the OpenWrt community seems not to be interested that much. Hm... Maybe the forum post was a bit too long, so it was perceived as a TL;DR? — Dsimic (talk | contribs) 00:05, 16 February 2015 (UTC)

Yes, maybe. But I still think it is a topic that manufacturers of routers should be thinking of. Look at Cisco, they offer $1000+ routers which have ECC capable processors and use ECC memory modules on them. They offer them as business-class routers to companies and they sell lots of them. By simply replacing the DRAM on a normal router with ECC DRAM, the manufacturers like Netgear, D-Link, etc. could reach a similar reliability than Cisco at a fraction of the price, in fact just a very little more than a normal router.

But anyway, the problem is to find a manufacturer who will adopt the technology and promotes it for his products. If they do, they will for sure sell a lot, win new customers, etc. It can impossibly be done by Intelligent Memory, because end-customers do not look at the chips, but they look at the features of the final product. 80.156.59.106 (talk) 08:52, 18 February 2015 (UTC)

Well, Cisco already enjoys good reputation, and large customers looking for reliability will always go and buy Cisco products, no matter how good-looking are alternative products from other manufacturers. I had some experience with certain "business/enterprise-class" Ethernet switches made by an "el cheapo" manufacturer, and they simply don't work well despite looking great on paper – and the misbehavior was consistent, not intermittent. Thus, making a truly reliable product would require much more than just equipping the hardware with ECC memory – though, the ECC memory on its own would be playing a very significant role. — Dsimic (talk | contribs) 20:38, 18 February 2015 (UTC)

Here's an update... A rather interesting RouterBOARD product equipped with 16 GB of ECC DRAM has been announced and should become available within a few months; here are a forum post and an article providing more details on Cloud Core Router CCR1072-1G-8S+, which is the announced product name. What's even more interesting is that the Tilera TILE-Gx processors used in the Cloud Core Router family of products seemingly support ECC memory, but the CCR1072-1G-8S+ should be the first actual product coming equipped with ECC SO-DIMM modules. Could it be that the manufacturers of embedded/networking equipment are slowly becoming aware of the importance of ECC memory? :) — Dsimic (talk | contribs) 08:44, 23 June 2015 (UTC)

SO-DIMM article

Thanks for planning on adding more references! I appreciate it, it'll measurably improve the article. --Yamla (talk) 19:23, 25 June 2015 (UTC)

Hello! You're welcome, and thank you for bringing up the lack of references. Having that list as part of the SO-DIMM article is actually very usable, will get the references added later today as promised. :) — Dsimic (talk | contribs) 19:55, 25 June 2015 (UTC)

Done as promised – added a total of eight new references, rescued an already existing one by using its archived version, and did some smaller wording cleanups. Please check it out. — Dsimic (talk | contribs) 04:03, 26 June 2015 (UTC)

Virtual machine article split

Hi Dragan,

The Virtual machine was a mash of 2 distinct concepts, with essentially no overlap: system virtual machine (OS virtualization etc.) and process virtual machine (JVM etc.). Thus I split them into two articles, and was in the process of cleaning them up. Shall we discuss at the article talk page? — Preceding unsigned comment added by Nbarth (talk • contribs) 17:21, 28 June 2015 (UTC)

Discussion started at Talk:Virtual machine#Split into separate pages for systems and process? —Nils von Barth (nbarth) (talk) 17:30, 28 June 2015 (UTC)

(edit conflict) Hello! I'd say that leaving the Virtual machine article as-is might be better than turning it into some kind of a disambiguation and moving its content to the System virtual machine‎ and Process virtual machine articles. The way Virtual machine article describes those two concepts is rather understandable to the readers, so it should be better to leave them together – that way, readers can grasp both concepts rather well without the need to shuffle through three articles. However, I'd suggest that you start a discussion on Talk:Virtual machine following the WP:SPLIT guideline, so we hear opinions from more editors. — Dsimic (talk | contribs) 17:33, 28 June 2015 (UTC)

HDD article reverts without discussion on talk page

Discussion on the talk page could improve the article (better than reverting mindlessly). If you find that quality adjusted price information from the Federal Reserve Board is in wrong section, I thing that moving it to the right section would help.71.128.35.13 (talk) 22:27, 7 July 2015 (UTC)

Hello! You're right and I apologize for not starting the discussion earlier. Please have a look at my reply in Talk:Hard disk drive § Editing reliable information and removal of speculation; hopefully, we'll reach an acceptable compromise. — Dsimic (talk | contribs) 22:37, 7 July 2015 (UTC)

SATA Express wiki page

Hi Dsimic,

Thanks for the explanation after you reverted some of our edits back to their original form. All makes sense.

However, with that said, we would like to request a few edits to the Serial ATA Express (SATA Express) wiki page: https://en.wikipedia.org/wiki/Serial_ATA_Express

Would you change the title of this page to SATA Express (as opposed to Serial ATA Express)? This is how the specification is usually referenced in papers and publications.
SFF-8639 connector is referenced as the device connector. Although it can be used that way, this connector is not part of the SATA Express spec. Is there anyway you could edit this to make it clearer to readers?

Let me know if you have any questions or concerns to the requests above.

Many thanks,

Jbalich (talk) 19:30, 11 October 2013 (UTC)

Hello there!

I'm glad you're Ok with the edits I performed. Thank you very much for your suggestions, especially regarding usage of the SFF-8639 connector — that's something I haven't described well enough within the article. Already went ahead and edited the SATA Express article so it properly describes used connectors, please check it out.

Also, I agree about the renaming, it's going to be shorter and better that way — and that's how all the papers are referring to the interface itself. I'll ask the admins tomorrow to perform the article renaming, can't do that myself as the SATA Express article already exists in form of a redirect (and copy&paste is not an option as commits history gets trashed that way).

-- Dsimic (talk) 05:46, 12 October 2013 (UTC)

Renaming of the article is done. :) -- Dsimic (talk) 02:25, 13 October 2013 (UTC)

Looks great, thanks for your edits to the connector section! Also, I appreciate your help in renaming the page! On another note, are you able to add an image to the SATA Express page? I found a simple yet informative image of hosts and drives from the SATA Express page on sata-io.org, found here: https://www.sata-io.org/sata-express — Preceding unsigned comment added by Jbalich (talk • contribs) 15:54, 14 October 2013 (UTC)

You're welcome. :) I'm glad you like it, and I'm really hoping that the whole article will help anyone in understanding better what's SATA Express about, as it can be quite confusing at the beginning.

Regarding adding images, Wikipedia is very, very strict about disallowing non-free images. I've already uploaded images of all five types of connectors used for SATA Express, in form of plain black-and-white sketches borrowed from a SATA-IO paper, and they were quickly deleted as disallowed. Well, it took me at least 45 minutes to crop, export and upload those wasted pictures. :) It's all about preventing any copyright issues down the road... Basically, unless it's a picture of a building that's been taken down, or a picture of no longer alive person — only the pictures you've taken yourself (or graphs created from an empty canvas) are allowed here.

-- Dsimic (talk) 16:09, 14 October 2013 (UTC)

I see, thanks for the clarification. If I had permission from SATA-IO (the owner of the above mentioned image) to post this image, how would I go about getting it up on the page? Once again, thanks for your help! Jbalich (talk) 16:43, 14 October 2013 (UTC)

You'd have to obtain a "free to use" license from SATA-IO for the particular image, in form of a page on their site explicitly stating such a license. With that available, you should provide URL of that page while uploading the image using the Wikipedia's File Upload Wizard (Toolbox --> Upload file on the left side of Wikipedia's standard layout). That would be basically it, together with adding image to the article itself.

Quite frankly, I'd say you'd be much better re-creating the illustration yourself, than chasing the SATA-IO for a license. You'd save yourself from a lot of pain. :) -- Dsimic (talk) 17:16, 14 October 2013 (UTC)

Got it, thanks again! Jbalich (talk) 17:29, 14 October 2013 (UTC)

You're welcome. -- Dsimic (talk) 17:35, 14 October 2013 (UTC)

Hi Dsimic,

I'd like to break out U.2 as a separate page for the connector formerly known as SFF-8639^[1]. There is a draft available now (https://en.wikipedia.org/wiki/Draft:U.2_(SFF-8639))

Thanks! Jmhands (talk) June 9, 2015 (UTC)

Hello! If I'm not mistaken, the draft you've linked above doesn't exist, and I've even tried one or two alterations of the draft name with no success. Any chances, please, for a working link to the draft you're referring to? — Dsimic (talk | contribs) 21:24, 9 June 2015 (UTC)

There was an extra parenthesis at the end. Please try: https://en.wikipedia.org/wiki/Draft:U.2_(SFF-8639) — Preceding unsigned comment added by 192.55.54.40 (talk) 21:07, 11 June 2015 (UTC)

Ugh, thanks – my bad, somehow managed to totally overlook that erroneous parenthesis. Had a look at the draft, it would require quite a lot of further work to qualify as an article. Jmhands, would you be Ok if I'd take your draft as a basis for the final version of the U.2 article? Of course, you'd receive appropriate attribution. — Dsimic (talk | contribs) 05:51, 12 June 2015 (UTC)

Of course - feel free to continue adding to the article to make it more clear. — Preceding unsigned comment added by 192.55.54.36 (talk) 14:24, 8 July 2015 (UTC)

Thanks, please also see my comments in the § Enlist your help to make U.2 (SFF-8639) page great! section below. By the way, I presume that an expression such as 192.55.54.0/24 == Jmhands holds true as those IP addresses belong to an address block assigned to Intel? :) — Dsimic (talk | contribs) 14:39, 8 July 2015 (UTC)

References

^ "2015technology | SFFWG Renames PCIe SSD SFF-8639 Connector To U.2". http://www.2015technology.com. Retrieved 2015-06-09. {{cite web}}: External link in |website= (help)

[1] "2015technology | SFFWG Renames PCIe SSD SFF-8639 Connector To U.2". http://www.2015technology.com. Retrieved 2015-06-09. {{cite web}}: External link in |website= (help)

[1]