Live data from Hacker News

Test your product on a crappy laptop

css-tricks.com

161–170 of 321 posts

Re: Test your product on a crappy laptop

#161
post #71
post #9

Microsoft was famous for testing the Mac version of Office on base model 60MHz PowerPC machines

They did the same for Windows 95: developers were given 386s with 4 MB of RAM to test on, because that was the minimum requirement for Windows 95. And in the end, it ran -- just about -- on those specs.

Did later editions (e.g. 95b) still run on the 386? I remember running 95b on a Pentium 166 MMX with 32MB of RAM and even that was a challenge at times!

Re: Test your product on a crappy laptop

#163

Any recommendations for a solid, representative crappy laptop? $100 xSomething Thinkpad off Ebay? Or is there something more representative of today.

T500/W500, 4GB of RAM. It's something like 13 years old, and ~$60. It can run almost every website that hasn't been web-dev'ed into oblivion. It balks at anything with memory leaks and inefficient CPU/GPU load. It can run YouTube/Facebook/Twitter (surprisingly, for the last). It can't run https://github.com/

Fairly impressed that it runs Facebook. Out of all the websites I use, I find Facebook to be the most slow (presumably due to its heavy use of JS). This is despite most other websites I use preforming fine on my personal 2017-era X1 Carbon and work 2017-era MacBook. I'd have thought it would fall off the rails on a 13 year old machine!

Re: Test your product on a crappy laptop

#164
post #41

There are three kinds of web developers: - Those who don't care about performance, as long as it loads within a few seconds on their own beefed up system on the LAN. This article is for them, and we can only hope they will listen. - Those who care about performance, and work for people who care. They are already doing great work (or are about to), producing those rare low-friction, high-speed, content-is-king sites w…

In my personal experience, even getting an average web dev to touch a slower Windows machine is mission impossible. The best you can hope is "ewww, this sucks so much and it's ugly, why would anyone do this" and then arrogant walk back to their 3000$+ MacBook to shovel more JS libraries into the website. I've literally not seen a single rockstart javascripter actually willingly try to test things on Windows, much less attempt to use a low/midrange machine to see if their code works well.

Re: Test your product on a crappy laptop

#165
Quite interestingly while building a WebGL application I had a slightly reverse experience. While it worked surprisingly fine on some older potato laptops, the experience on Macbooks with retina screen was consistently problematic. That was due to the sheer resolution that had to be rendered per each frame. Took quite a bit of optimisation work to improve it.

Re: Test your product on a crappy laptop

#166

I ve always wondered why all computers don't have a "slow down" setting

They have, kind of, it's the energy save mode. On Linux, (besides GPU) you'd set /sys/devices/system/cpu/cpu$i/cpufreq/scaling_max_freq to cpuinfo_min_freq, for all $i. I always look for minimum (idling) CPU frequency in devices before buying them, but this info is almost never available. My laptop has a min freq of 800 MHz, but I would like to go even lower, to better test low performance devices and limit energy us…

There are two ways you can go lower: the cpu cgroup, and cooling_deviceN. I'm still working on memorizing the first approach :) but it works well just about everywhere; the second is simpler but employs intel-specific hardware-level throttling which may or may not behave usefully (it may have been the cause of a couple of mystery soft hangs on an old Pentium box I have here, presumably things are less glitchy now given how frequently laptops throttle nowadays).

While the cgroup approach is (like cpufreq) doable by poking around in /sys/fs/cgroup (you mkdir new directories to create cgroups), cgroup-tools makes it a tad more straightforward by making the steps less verbose. (Besides cgroup-tools, "unshare" and "nsenter" ship with util-linux and can issue the syscalls necessary to start a process in a given cgroup, which you can't do with pure bash.)

The setup is always the same - you create a new "cpu" cgroup (here named "cpulimit"), then configure CFS (completely fair scheduler, I think? I thought there were multiple schedulers... maybe this only applies if using CFS? I think CFS is the default everywhere) with a period and quota. I think the period is used to derive an internal tick rate. The quota is a fraction of the period and the ratio (yay you get to do the math yourself) represents how much CPU the task gets to eat. I think the ratio applies across all the CPUs. I have no idea what happens if you bring PID-level CPU affinity into the equation. Maybe you can select which CPUs are enabled for the cgroup, and the math applies to whatever's enabled. Haven't answered any of that yet. In any case:

  # cgcreate -g cpu:cpulimit
  # cgset -r cpu.cfs_period_us=1000000 cpulimit
  # cgset -r cpu.cfs_quota_us=100 cpulimit
A fairly straightforward demonstration: in one terminal run

  # cgexec -g cpu:cpulimit yes | pv -l > /dev/null
while in another terminal rerun the last `cgset` with quotas of 1000, 10000, etc, and watch the output rate go up and down. (In this case 100 is a good starting value, but anything more complicated than printf(); in a loop will probably finish launching in 2023 if started with a quota of 100.)

The nice thing is that the cgroup happily sits in the background until explicitly deleted (and systemd leaves everything it didn't create alone) and you can just poke at its values anytime. Network cgroups can probably do interesting fun things to traffic as well (oh yeah, network namespaces = discrete iptables/nftables per namespace).

Lastly, the cooling_deviceN entries are in /sys/class/thermal, and have cur_state and max_state. YMMV; setting cur_ to max_ may well take several minutes to undo (very much the case on older systems at least) - maybe try that on a throwaway-able session. :D (Think "Task Manager (Not Responding)"...)

Re: Test your product on a crappy laptop

#167

> British soldiers in World War I were equipped with a Brodie helmet, a steel hat designed to protect its wearer from overhead blasts and shrapnel while conducting trench warfare. After its deployment, field hospitals saw an uptick in soldiers with severe head injuries. > Because of the rise in injuries, British command considered going back to the drawing board with the helmet’s design. Fortunately, a statistician p…

We apply this kind of thinking at work: early on we focused all our energy fixing user problems or adding features that were requested. We realised it is actually a small number of users who volunteer to report to us what's wrong or missing (outside of regular crash/feature tracking) - they are the ones that care enough to make an effort, and it's a small percentage. So we started campaigning to engage users we never…

Did those users actually report different issues altogether from the original ones, or did they just report more of the same kinds of issues?

Re: Test your product on a crappy laptop

#168
The point they make is more than valid.

I don't like the attitude calling them craptops. A Gigabyte of memory and 10 Mbit/sec are enough to meet 99.9% of the user needs for Web browsing. If sites were implemented in a resource-aware manner of course.

Instead of looking down at craptops I would look down at people introducing 4K and using many Gigabytes of memory for personal computing. Even worse making masses use it. It's irresponsible greed and short-sighted capitalism that ruins the planet.

Re: Test your product on a crappy laptop

#169

I had a similar experience building a NAS on a SoC. Suddenly things like transport or at rest encryption are no longer perceived to be free but really limit your performance. First time I actually had to be concious about choosing appropriate ciphers and hashing algos and not just using defaults.

What config did you end up setting with, if you happen to have the info easily to hand? I might be able to speed up SSHing to some of the slower hardware I have here.

Also, I'm very curious what SoC this was.

Re: Test your product on a crappy laptop

#170
post #71

Earlier quoted context omitted.

They did the same for Windows 95: developers were given 386s with 4 MB of RAM to test on, because that was the minimum requirement for Windows 95. And in the end, it ran -- just about -- on those specs.

Did later editions (e.g. 95b) still run on the 386? I remember running 95b on a Pentium 166 MMX with 32MB of RAM and even that was a challenge at times!

OSR2 ran pretty nice on 486 DX2 with 16MB of RAM
Post reply on HN