February 2018 - Talk - lists.gtalug.org

Intel straws and Camel's backs [WAS: life expectancy of 32-bit x86]
by Giles Orr 14 Feb '18

14 Feb '18

On 14 February 2018 at 14:32, D. Hugh Redelmeier via talk <talk(a)gtalug.org> wrote: > > | > Almost NO 32-bit x86 chips are in current production. I think that > | > Intel has some goofy SoCs for IoT applications that are limited to > | > 32-bit but they really don't matter. > | > | No, they canned that line last year. They really were not very good. > > This doesn't say that it is EoLed. But I do think I heard that they > stopped work in this direction. > > <https://ark.intel.com/products/91949> > > The "segfault bug" (lock instruction (prefix?) bug) sounds bad: > <https://en.wikipedia.org/wiki/Intel_Quark#Segfault_bug> > That's an awesome solution they implemented there: "don't use LOCK." Intel says "It's 2014, you don't need multi-threading!" There's this assumption among many computer geeks (until today I was among them) that Intel is the chip "gold standard." I _should_ have changed my mind on that after their spectacularly poor response to Spectre and Meltdown. And then there's the security nightmare of the IME, a horribly insecure computer-within-your-computer. But for some reason, I think this is the figurative straw that broke the camel's back: I'm going to be looking to other chip manufacturers after this. All my vehemence and reading https://en.wikipedia.org/wiki/Intel_Management_Engine shows that AMD has created their own IME-alike. Security is a thing of the past ... -- Giles https://www.gilesorr.com/ gilesorr(a)gmail.com

2 1

RAM speed matters in Ryzen
by D. Hugh Redelmeier 14 Feb '18

14 Feb '18

My impression has been that for ordinary workloads, RAM speed hasn't mattered much recently. The reason, I assumed, is that modern processors had pushed caches and out-of-order execution quite a distance. This article shows that the Ryzen 5 240g performance is affected by RAM speed. The article doesn't mention number of channels, but that should matter too. <https://www.extremetech.com/computing/263783-evaluating-ddr4-scaling-ryzen-…> How come? I suspect that the clue is here: "The CPU-GPU interconnect system uses AMD’s Infinity Fabric as well, and Infinity Fabric’s clock is directly tied to DRAM clock." I wonder if cranking up the DRAM clock, but adding latency cycles, would improve performance without requiring faster RAM.

1 0

HackLab.TO's Junk Independence Day is this Sunday from 2pm to 7pm
by Myles Braithwaite 👾 14 Feb '18

14 Feb '18

<https://hacklab.to/archives/just-announced-junk-independence-day/> It’s everyone’s favorite time again: the first Junk Independence Day of 2018! Coming up on February 18th from 2pm-7pm (or later). Bring your e-waste and dig through other people’s for treasures. On previous Junk Independence Days, people have walked away with an iPod touch, a 1TB hard drive, working classic iMacs, bubblejet printers, a Sony mini-DV camcorder, stereo amps, speakers, a desktop computer and even walk/don’t walk streetlights! Not to be forgotten, there are always lots of little chips and bytes for random hacking, too. Anything left at the end will be picked up on Tuesday, 20th of February and responsibly recycled by Revolution Recycling, who has been participating in our Junk Independence Days since the first one. Thanks Revolution!! Come hang out with some fellow hackers and search for hidden treasures! Tickets are not necessary but Eventbrite[0] is a great way to sign up and get reminders. You can also RSVP via our Facebook event[1]. See you at JID! HackLab.TO is located at 1266 Queen St. West, Suite #6[3]. [0]: <https://www.eventbrite.ca/e/junk-independence-day-tickets-43005470520> [1]: <https://www.facebook.com/events/1574038156049596/> [3]: <http://www.openstreetmap.org/node/3522641496> (feel free to share this message with awesome people)

1 0

Feb. 13, 2018 Dinner Location?
by Ivan Avery Frey 13 Feb '18

13 Feb '18

Where are we meeting tonight for dinner?

3 3

kpti kaiser meltdown performance
by Russell 12 Feb '18

12 Feb '18

I thought I'd pass this link along. Brendan Gregg is a performance engineer for Netflix, also a real outside the box thinker. One of his other blog posts is about his video recording of an eclipse. He turned his camera away in order to observe the "far field" effect on the environment around him, rather than record the event itself. Outside of this he has a good narrative style which I am able to follow. http://www.brendangregg.com/blog/2018-02-09/kpti-kaiser-meltdown-performanc… -- Russell

1 0

printer options
by D. Hugh Redelmeier 09 Feb '18

09 Feb '18

I usually like printing on both sides of a piece of paper. For arcane reasons, this is called "duplexing" (a lot of printing terminology is arcane). When I buy a printer, I always try for one that can do automatic duplexing. Context: I use Fedora with Gnome and CUPS. For years now, I've been a little perplexed why my printing from GUI applications is duplex and from other applications, is single-sided. I now know more of the answer. >From the GUI settings menu, you can set default printer options. From the print dialogue box of GUI applications, you can also set this option. Page Setup: Two-sided can be One Sided Long Edge (Standard) Short Edge (flip) These options don't affect printing from non-GUI programs (eg. lpr and alpine). For that, you use the lpoption command lpoptions -o sides=two-sided-long-edge (Notice the different terminology?) It surprised me to learn that options settings are persistent. lpoptions(1) saves the setting in ~/.cups/lpoptions. Reading the lpoptions manual, I thought that it was the other way around: that a user could edit this file and lpoptions(1) would take that as a starting point. A good thing too, since the format of the file is not documented. You can also put the options on some commands directly, for example lpr(1). If root executes lpoption(1), the file /etc/cups/lpoption will record the result. Ordinary programs that are not running as root consult this file as well as ~/.cups/lpoptions It seems goofy and annoying that the two different ways of setting printer options don't communicate. Printer settings can get even more complicated when you look at ppds. I think that is because different printers have different settings.

2 1

'file' maintainer? (or fun with PIE and magic)
by Stewart C. Russell 08 Feb '18

08 Feb '18

Anyone know how to get in touch with the maintainers of 'file'? Seems the links in the man pages and Ian Darwin's site - http://www.darwinsys.com/file/ - don't work. The file magic database needs an update to correctly recognize PIE (Position Independent Executable) x86 ELF binaries as application/x-executable. This might seem an incredibly trivial thing, but it effectively stops graphical file managers from executing binaries, as they use magic (5) to identify files. Debian switched to making PIE a default for gcc for security reasons, but probably didn't expect it to break graphical UIs. Here's what I'm seeing: Expected behaviour: $ echo "int main() { return 0; }" > foo.c $ gcc -o foo foo.c $ file foo foo: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=6e7749f995a89a53f74ec29d3c16fcf3f56be90f, not stripped $ file --mime-type foo foo: application/x-executable Actual behaviour: $ echo "int main() { return 0; }" > foo.c $ gcc -o foo foo.c $ file foo foo: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=6e7749f995a89a53f74ec29d3c16fcf3f56be90f, not stripped $ file --mime-type foo foo: application/x-sharedlib Workaround: $ echo "int main() { return 0; }" > foo.c $ gcc -o foo-nopie foo.c -no-pie $ file foo-nopie foo-nopie: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=3eb8c581f43c19997e3c828f5a9730dbdc794470, not stripped $ file --mime-type foo-nopie foo-nopie: application/x-executable I'm a bit worried that the workaround allows less safe binaries to be double-clicked and run. I'm not sure how much of a security issue PIE vs non-PIE is, though. cheers, Stewart

4 7

Fw: Meltdown and Spectre on HTTP workload
by Steve Petrie, P.Eng. 07 Feb '18

07 Feb '18

Warm Greetings To GTALUG, FYI. Below is a forward of an email from one of the developers of the DragonFlyBSD (dfly) operating system. The PDF at the link target gives a nice one-page graph showing the performance hits due to fixes for Meltdown and Spectre. Dfly is not LInux but a highly performant BSD flavour I have installed dfly for testing under a VPS. Thinking to use dfly, instead of Linux, for better HTTP server resource efficiency. But also always keeping the website operational under a debian Linux for development, reference, maintenance and emergency fallback. Steve ----- Original Message ----- From: Sepherosa Ziehau To: users(a)dragonflybsd.org Sent: Tuesday, February 06, 2018 8:44 AM Subject: Meltdown and Spectre on HTTP workload Enjoy: https://leaf.dragonflybsd.org/~sephe/melt_spectre.pdf Meltdown+spectre means that performance is dropped by 35%, and 99th percentile of latency is increased by 55%! Thanks, sephe -- Tomorrow Will Never Die

1 0

[GTALUG-Announce] GTALUG Meeting on Tuesday 13 February at 7:30pm
by hi＠gtalug.org 06 Feb '18

06 Feb '18

<http://gtalug.org/meeting/2018-02/> # Postgres, MVCC, and You (or, why COUNT(*) is slow) with David Wolever It's hard to be a developer today without using a database… but they're often surrounded by an air of reverent mystery. One of those mysteries is why it's so slow to count all the rows in a table using COUNT(*). After all, it's just a matter of walking a b-tree and counting leaves… and that should be trivial to optimize! In this talk I'll answer the question of "why COUNT(*) is slow" by taking a deep dive into the the internals of Postgres' MVCC implementation, looking at: The question of "why COUNT(*) is slow" The on-disk storage layout and why, under the hood, it's not a b-tree What Postgres means by MVCC, with examples of the utility of transactions Introduce xid, xmin, xmax Discuss tuple visibility Explain VACUUM and xid wraparound Show off transaction isolation levels This talk is accessible to anyone who's used an SQL database, with enough depth that experienced developers will find some interesting tidbits. About me: David is a Pythonista from Toronto, Canada. He's co-founder of both PyCon Canada – Canada's regional Python conference – and Akindi.com – a small company that's making multiple-choice bubble sheet tests a little bit less terrible. He's also the author of nose-parameterized, a parameterized testing for every Python testrunner, and pprint++, a Python pretty-printer that's actually pretty. Say hi on Twitter: @wolever! ## Location George Vari Engineering and Computing Centre 245 Church Street, Room 203 Ryerson University <http://goo.gl/maps/16oJ2> <http://www.openstreetmap.org/way/23447525> ## Schedule * 6:00 pm - Please discuss on the general mailing list (i.e. <talk(a)gtalug.org>) where you want to go for dinner. * 7:30 pm - Meeting and presentation. * 9:00 pm - After each meeting, a group of GTALUGers move to The Imperial Pub (54 Dundas St East) for refreshments and more socialising. # Code of Conduct We want a productive happy community that can welcome new ideas, improve every process every year, and foster collaboration between individuals with differing needs, interests and skills. We gain strength from diversity, and actively seek participation from those who enhance it. This code of conduct exists to ensure that diverse groups collaborate to mutual advantage and enjoyment. We will challenge prejudice that could jeopardise the participation of any person in the community. The Code of Conduct governs how we behave in public or in private whenever the Linux community will be judged by our actions. We expect it to be honoured by everyone who represents the community officially or informally, claims affiliation or participates directly. It applies to activities online or offline. We invite anybody to participate. Our community is open. Please read more about the GTALUG Code of Conduct here: <http://gtalug.org/about/code-of-conduct/>. If you have any questions, comments, or concerns about the GTALUG Code of Conduct please contact the GTALUG Board @ <board(a)gtalug.org>. --- GTALUG Announce mailing list announce(a)gtalug.org https://gtalug.org/mailman/listinfo/announce

1 0

more on Spectre v2
by D. Hugh Redelmeier 05 Feb '18

05 Feb '18

Spectre v2 is really complicated to deal with. Just read this recent thread in the LKML <https://lkml.org/lkml/2018/1/20/158> I'm impressed how well written those messages are. Intel Skylake CPUs are particularly problematic. Those are most of the "6th generation Core" processors and some of the "7th generation Core". <https://en.wikipedia.org/wiki/Skylake_(microarchitecture)> The indirect branch predictor is a big problem. The retpoline deals with most cases. On Skylake, this predictor is used in another case: for return instructions that cause underflow in the call/return predictor stack. That means that EVERY return instruction is suspect, and the cost of being suspect is high. OK, if you can prove that the call/return predictor stack has not underflowed, you can just do a return. But how? The best fix is not on the table: it would be great if Intel could patch microcode so that the return predictor did not fall back to the indirect branch predictor. It sounds easy, but I infer that it is not technically possible.

2 3