msimpson

The link within that README leading to what "Signed-off-by" means is now broken. Use:

https://gerrit-review.googlesource.com/Documentation/user-si...

It also contains ad blocker detection which gates the article until you disable it.

I would say that this should be taught in driver education courses, but seeing as Maryland has removed even parallel parking from their test I have very little hope left.

They seem to be a government contractor.

I see you've already asked, as well pvg. Thanks.

Where is he on this thread?

> Does it matter?

Yes, as this seems to be an initial marketing attempt by Kyle Spearrin (the creator of Bitwarden) to unveil his own LastPass alternative while simultaneous making LastPass seem untrustworthy. Regardless of whether the issue detailed in this article is true, the following timeline cannot be ignored:

1. Bitwarden.com was registered on Nov. 16, 2015

2. The initial commit to bitwarden/core was on Dec. 8, 2015

3. Release v1.3.0 of Bitwarden is issued on Jan 16, 2017

4. A quick fix release v1.3.1 is issued on Jan 17, 2017

5. Bitwarden.com gains an SSL certificate on Jan. 17, 2017

6. This article arrives touting an unknown LastPass alternative on Jan. 18, 2017

Suspicious? I am. Especially since Kyle is the only contributor to the project, as well.

Medium is having issues: https://medium.statuspage.io/

Refer to the following, taken from that guide:

  4.1 T_CASE and DTS-Based Thermal Specification Implementation

  Thermal solutions should be sized such that the processor complies to the T_CASE
  thermal profile all the way up to TDP, because, when all cores are active, a thermal
  solution sized as such will have the capacity to meet the DTS thermal profile, by
  design. When all cores are not active or when Intel Turbo Boost Technology is active,
  attempting to comply with the DTS thermal profile may drive system fans to speeds
  higher than the fan speed required to comply with the T_CASE thermal profile at TDP.

  In cases where thermal solutions are undersized, and the processor does not comply
  with the T_CASE thermal profile at TDP, compliance can occur when the processor power
  is kept lower than TDP, AND the actual T_CASE is below the T_CASE thermal profile at that
  lower power.

  In most situations, implementation of DTS thermal profile can reduce average fan
  power and improve acoustics, as compared to T_CONTROL -based fan speed control. When
  DTS < T_CONTROL , the processor is compliant, and T_CASE and DTS thermal profiles can
  be ignored.

  5.3.1 Intel ® Turbo Boost Technology

  Intel ® Turbo Boost Technology is a feature available on certain Intel ® Xeon ®
  processor E5-1600 and E5-2600 v3 product families SKUs that opportunistically, and
  automatically allows the processor to run faster than the marked frequency if the part
  is operating below certain power and temperature limits. With Turbo Boost enabled,
  the instantaneous processor power can exceed TDP for short durations resulting in
  increased performance.

  (http://www.intel.com/content/dam/www/public/us/en/documents/guides/xeon-e5-v3-thermal-guide.pdf)

This means that as long as you give the CPU a thermal solution capable of dissipating a thermal wattage equivalent to the CPU's temperature, at its case, when it reaches TDP, you're good. However, if you push the processor into Turbo Boost (like Atwood did with mprime), the CPU can exceed TDP for short durations. And, while all this is happening, the Thermal Control Circuit (TCC) is managing the thermal output by adjusting the clock, frequency, and input voltage automatically so the CPU stays away from operational limits. Therefore, if you intend to run this CPU under a sustained heavy load you must supply a thermal solution beyond TDP.

Intel literally spelled that out in this PDF which they linked from their TDP definition on every CPU specification page.

Now, in terms of power consumption. You must consider the entire system as the CPU is going to manage itself to fit its environment given the TCC. That is why Intel suggests you measure overall consumption for the server using a power meter as each implementation can yield different results. Therefore, what Atwood is doing is actually Intel's recommendation for considering actual power consumption. He, as I originally stated who knows how many replies ago, is making the mistake of directly equating power consumption to heat dissipation. When all you can really be sure of is that if a CPU consumes 1 watt of power it can dissipate up to the same in heat. But, as thermal dynamics will tell you, it will always be a bit less on the output as nothing is 100% efficient.

Therefore, all Atwood's test proves is an Intel® Xeon® Processor E5-1650 v3 has the potential to dissipate up to 250 watts of heat while in Turbo, given its recorded power consumption, in that specific computer configuration while running mprime. Nothing more, nothing less.

That is my point.

TDP is used by multiple manufacturers, so getting a "coherent definition" is going to take work. If you want to understand more about the thermal specs from only Intel. You can read their thermal guide:

http://www.intel.com/content/dam/www/public/us/en/documents/...

Let's get to the crux, here:

> Unless your "typical load" used for determining TDP does not actually make use of the full number of cores

> If the 4 core actually needs to dissipate 140W under a typical use case, then the 6 core should absolutely need to dissipate more unless the "typical use case" is uselessly applied.

Taken from Intel's own specs for the E5-1650:

"Thermal Design Power (TDP) represents the average power, in watts, the processor dissipates when operating at Base Frequency with all cores active under an Intel-defined, high-complexity workload. Refer to Datasheet for thermal solution requirements."

Immediately notice "Base Frequency", not Max Turbo, "all cores active", and "Intel-defined, high-complexity workload." Until you can perform the same test on both chips, you cannot assume that "these two processors should be dissimilar under any load."

In regard to your car analogy, if the sport version had a management interface to limit speed due to the rating on the tires, then it would be like an Intel CPU. Read this:

http://www.intel.com/content/dam/www/public/us/en/documents/...

> They simply have to release a coherent definition of what they consider a typical load.

Have fun getting AMD and Intel to agree on something.

> I get your point, but nothing wrong in drawing attention to the specs being incomplete to the point of being useless.

Vague or averaged is not useless.

>Is there a standard load for measuring TDP then?

No. Different manufacturers use different definitions of what a typical load means.

> If not, how would you attempt to test it other than placing the processor under heavy load?

Well given that Intel has stated, "The TDP is not the maximum power that the processor can dissipate." Then testing under heavy load is most certainly not correct.

So if TDP is a measure, given in wattage, of thermal dissipation of a CPU under a typical load. Why can't I simply assume double that value for a CPU's actual power consumption under heavy load?

I mean, using that logic the max power consumption for the same six core processor Atwood tested would be around 280 watts. A number only 40 watts higher than his for heavy load. Too bad I used "false information" to reach such a usable number.

Now if the actual power consumption was double that, I'd definitely be berating Intel. But alas, no.

As I said, "variables that can amount to TENS of watts."

No. He's measuring the difference in overall power consumption of the same computer using two different processors under two different states: idle and heavy load. Two states which TDP does not seek to measure.

Again, TDP is NOT peak thermal dissipation.

> So if we assume that Intel's 4-core is actually 140W TDP, then there's no way this 6-core can also be 140W.

Why? How can you say that under typical usage the thermal dissipation for both chips isn't the same? Atwood's numbers measure overall power consumption while idle and under heavy load with mprime, neither of which is what TDP seeks to measure.

TDP is like fuel economy for cars. You don't claim it's a lie when you go one hundred and fifty miles an hour for 20 miles and burn two gallons of gas. You simply realize those highway numbers are meant for more of a sixty mile per hour journey over the same distance.

The author is comparing how off overall power consumption is from the stated thermal design power under a sustained, heavy load; which is not what TDP is intended to measure ...

"TDP is not the maximum power that the processor can dissipate." -- Intel

Keep in mind that TDP is only a target number for typical use, not mprime. Not to mention Intel and AMD define it differently, see:

http://www.silentpcreview.com/article169-page3.html

"Intel is listing TDP numbers that are significantly lower than the actual maximum power draw of their CPUs."

That article is THIRTEEN YEARS OLD!

From Intel:

"Thermal Design Power (TDP) should be used for processor thermal solution design targets. The TDP is not the maximum power that the processor can dissipate."

"Analysis indicates that real applications are unlikely to cause the processor to consume maximum power dissipation for sustained periods of time. Intel recommends that complete thermal solution designs target the Thermal Design Power (TDP) indicated in Table 26 instead of the maximum processor power consumption. The Thermal Monitor feature is intended to help protect the processor in the unlikely event that an application exceeds the TDP recommendation for a sustained period of time."

Therefore, are Atwood's test results really a shock? At idle both chips are within 15 watts of each other, yet under sustained load (which is not what TDP seeks to measure) they both violate their advertised TDP.

When you're arguing over a 110 watt difference, 50 watts lost as heat in the PSU is not insignificant and certainly enough to skew a test.

Yet, he is not measuring the Vcore going into the CPU. He is measuring the overall wattage consumed by the PSU at the outlet using a Kill-a-Watt. This contains a lot more draw than just the CPU, itself. That's an overwhelming lack of concern for a wealth of other variables that can amount to tens of watts. So to be more concise:

Overall energy consumption of a computer does not equate to only the TDP of the CPU, itself.

How does one limit city density? Population growth creates cities. Not the other way around.

How do you measure TDP with a Kill-a-Watt? Energy consumption does not equate to thermal design power. Nor is TDP even a measure of peak thermal output ...

You can apply the same argument to fresh water access. Urbanization is not conducive to individualized sustainability. You either come to terms with that or move out to the sticks and adopt a DIY attitude toward survial.

"It pretends that vanishing institutional knowledge of growing food isn’t a problem; we should be TERRIFIED that fewer than 1 in 100 Americans actually knows how to grow enough food to feed a family or more."

Why? There are many other vital survival tasks that the overwhelming majority of the world's population cannot perform. This is merely the consequence of living in modern society; such efforts are abstracted away from the consumer. People will educate themselves when such information becomes necessary.

Also, fabricating dramatic statistics doesn't help anyone. I can quote a Farm and Dairy article from three years ago which stated, "One in 3 households are now growing food — the highest overall participation and spending levels seen in a decade." And that, "Households with incomes under $35,000 participating in food gardening grew to 11 million — up 38 percent from 2008."

Should I be less "TERRIFIED" now?

Personally, I love Systemd for Web development as it makes the job of managing Node.js projects a breeze. I simply pack a Systemd unit file into a project's repository as part of its multi-environment configuration and construct deployment tasks to copy, enable, then start the unit file.

1. Copy <unit.service> to the sever, which looks like:

  [Unit]
  Description=<name> Service
  After=network.target

  [Service]
  Restart=always
  StandardOutput=syslog
  StandardError=syslog
  SyslogIdentifier=node-<name>
  User=<user>
  Group=<group>
  WorkingDirectory=/srv/node/<name>/current/
  Environment="NODE_ENV=production"
  Environment="PORT=2580"
  ExecStart=/usr/bin/node server.js

  [Install]
  WantedBy=multi-user.target

2. Enable the unit file in place:

  sudo systemctl enable /srv/node/<name>/config/<unit.service>

3. Start the unit file:

  sudo systemctl start <unit.service>

And, of course, destroying that deployment is just as easy.

Did you actually read the article or just these comments?

Thanks. I'm still waking up.

I'm optimistic in that there may finally be a self-hosted version of Trello.

Waits patiently for the mail client.