Element ELST5016s review: TV input lag, deinterlacing and upscaling using the piLagTesterPRO

This is a 1080p "smart" TV from 2017. While it's not a standout in any dimension it does everything well, and is a balanced choice for gaming, both modern and retro. The lag is much better than average, and the upscaling is also better than average. It's smart functionality is a bit mediocre, but that's not why you are here, right?

Image quality

Good upscaling is critical for retro gaming. Ideally, all pixels should appear equally sharp and bright (no aliasing), and angled lines should appear smooth, with no jagged, irregular steps. Also important is that the display shows most or all of the pixels it is sent. Often, this is not the case, with some number of pixels cropped from the bottom or top edges. Shockingly, these tests are relevant for modern gaming as well, because even at their native resolution many TVs have aliasing and cropping.

I attempted to adjust the set to minimize cropping and aliasing. On this set scaling and aspect ratio are combined under a single option called "aspect". Your options include a couple way-zoomed-in modes, a just-scan option that does zero cropping but always uses 16:9, and two moderately cropped settings, one 16:9 and the other 4:3. Interestingly, this TV has a somewhat hidden service menu, (press 0 a bunch of times on the main menu) which gives to-the-pixel control over cropping. But unfortunately it doesn't seem to save this over a power cycle, so I didn't use it for the report below. 

resolution	quality	cropping (side, top)
480p/i	A. Mild over sharpening and halos, but the overall result is nearly as good as you ever outside of a dedicated scaler.	10,13
720p	A. Pixels get rearranged such that a 1-pixel checkerboard is no longer a checkerboard, but most detail is preserved and there's no aliasing and no cropping.	0,0
1080p	A. Even in just-scan there's a tiny bit of aliasing even though there's no cropping. Bizarre, but the effect is very mild. Possibly what I'm really seeing is over sharpening, not aliasing from resizing.	0,0
960p	B- (4:3), A-(16:9). This resolution is a favorite with the OSSC crowd, but doesn't look that good on this TV. Might as well use 480p output from the OSSC since this TV does good upscaling at that resolution.	0,0

Overall this set does a good job of upscaling. No resolution is perfect but all are handled pretty well. In fact this might be the best well-rounded TV I've seen. Since it does such a solid job in all standard resolutions, the 960p results, while disappointing, are not a big deal for OSSC users, as they can just use 480p.

The display has 3 HDMI, 1VGA, and 1 yPbPr input. I only tested HDMI.

Input Lag

I used a piLagTesterPRO to measure input lag. This device sends a frame of video over HDMI and measures how long it takes to display it. This display does not have a game mode; not even a game 'color' preset. I toggled all the display quality settings and did not see a consistent effect on lag, however the tests reported are with every "enhancement" set to off.

Input Lag Test Results

I report two kinds of values. 1st response measures how long it takes for the TV to start responding (I use a 5% change in display brightness). This overly optimistic value doesn't tell how long it takes to see anything useful, but matches what other reviewers call input lag. full response is a more realistic measure of lag, and requires the display to reach 80% of full brightness. This combines both input lag and response time, and is closer to what you would actually experience in a game.

	top		bottom
Resolution	1st response	full response	1st response	full response	scan out
480i	39.6	47.6	55.5	63.5	15.9
480p	22.7	30.7	38.4	46.4	15.7
720p	21.4	29.4	37.1	45.1	15.7
1080p	21.5	29.5	37.3	45.3	15.8
1080p50	28.2	36.2	44	52.0	15.8
1080p24	55.8	63.8	71.5	79.5	15.7

This set advertises a huge range of supported modes, and actually it probably supports any reasonable resolution and refresh rate that's sub 1080p60. For progressive sources at 60hz, the input lag (first response) is consistently 22ms, the response time is 8ms, and the scan out is 16ms. Deinterlacing adds 16ms. The TV also supports a number of other refreshes rates. In particular, 1080p PAL (50hz) and film (24hz) are handled perfectly, with no dropped frames or drifting lag. Interestingly, the scanout is the same 60hz rate; the TV just waits longer to start drawing until the required data has been sent over HDMI, but once it starts drawing it goes at the full speed.

The TV also reports that it can support some computer modes that refresh at 72 or 75 hz. This is both a lie and true: it still draws the screen 60hz and thus has to drop frames, but it will at least accept these inputs and display them. I would strongly advise against using these modes as the higher refresh rate in no way improves the lag.  For anybody who cares, here's the raw data for the full response at the bottom of the screen for all supported modes. It's sorted by the average drift in lag per second, so the results at the bottom are modes where the TV cannot actually match the input refresh rate.

mode name	res/refresh	full response	variability
dmt#83	900p60	38.1	0.02ms
dmt#47	900p60	37.2	0.04ms
dmt#16	768p60	37.4	0.05ms
cea#16	1080p60	37.3	0.06ms
cea#19	720p50	43.9	0.06ms
cea#4	720p60	37.1	0.07ms
dmt#39	768p60	37	0.07ms
dmt#58	1050p60	37	0.07ms
cea#5	1080i60	53.8	0.08ms
cea#17	576p50	45.3	0.09ms
cea#18	576p50	45.2	0.09ms
cea#32	1080p24	71.5	0.10ms
cea#6	480i60	55.4	0.11ms
dmt#9	600p60	37.3	0.12ms
cea#1	480p60	38.5	0.14ms
cea#2	480p60	38.3	0.14ms
cea#3	480p60	38.4	0.14ms
cea#20	1080i50	64	0.14ms
cea#7	480i60	55.4	0.16ms
cea#31	1080p50	44	0.16ms
dmt#4	480p60	38.5	0.16ms
cea#22	576i50	65.5	0.23ms
cea#21	576i50	65.6	0.24ms
dmt#8	600p56	46.3	1.09ms
dmt#5	480p72	42.7	2.18ms
dmt#18	768p75	42.8	2.82ms
dmt#36	1024p75	41.7	3.01ms
dmt#17	768p70	42.7	3.65ms
dmt#6	480p75	42.8	6.70ms
dmt#11	600p75	42.9	6.85ms
dmt#10	600p72	42.1	8.25ms

Results compared to other displays

To allow quick comparison between many displays I've summarized the results across all the mainstream displays I've personally tested with the piLagTester Pro. Min lag is the time to the first response, measured where the screen starts drawing (typically, the top); real lag is the time to the full response, measured where drawing finishes (usually the screen bottom), i.e. input lag + scan out + response time. Numbers in red denote average values that can vary by up to 8ms between power cycles.

This list is sorted by real lag for each display's native resolution and max refresh rate (usually 1080p60 but some sets are 720p60, and other monitors support > 60hz).

Display	Year made (TV?)	Native Res	native min lag	native real lag	480i real lag	480p real lag	720p real lag	1080p real lag	native response time	native scan out
Dell E198FPb	2008	1024p	2.7	20.4		39.0	35.0		5.00	12.70
Samsung 2494sw	2011	1080p	2.8	22.7		26.5	26.5	26.5	8.00	13.30
Vizio VO370M	2010	1080p	2.5	23.6	83.0	49.0	47.0	24.3	5.47	15.67
LG W1953T	2010	768p	2.6	25.6		28.7	28.7		10.00	13.00
Dell U2410 (game)	2010	1080p	4.0	26.2	62.2	28.3	26.5	26.5	6.00	16.20
TCL 40S325	2021	1080p	6.5	27.3	60.6	29.0	27.9	27.7	6.00	14.83
TCL 49s403	2018	4k	6.1	30.2	76.8	30.9	30.3	30.7	8.00	16.13
Dell E2211H	2014	1080p	3.0	33.6	34.7	34.5	34.1	33.8	15.00	15.57
Panasonic TH-58PE75U	2008	720p	28.0	34.0	34.0	34.0	34.0	34.0	6.00	0.00
Corprit D157 (hdmi)	2021	1080p	3.1	34.5	34.9	34.8	34.6	33.9	16.25	15.13
Samsung S27C230	2014	1080p	2.9	36.0		36.6	36.1	36.1	18.10	14.97
Vizio E470VL (vga)	2011	1080p	22.0	39.0		39.0	39.0	39.0	9.00	8.00
Samsung LN32D403	2012	720p	20.9	41.2	58.9	42.4	40.7	40.7	5.50	14.83
TCL50s423	2021	4k	14.0	42.0	75.0	42.0	42.0	42.0	13.00	15.00
sony XBR 43X800D	2017	4k	24.5	44.3	46.5	46.0	44.6	44.7	5.00	14.83
Element elst5016s	2017	1080p	21.4	45.1	63.5	46.4	45.1	45.3	8.00	15.73
RCA L40FHD41	2010	1080p	20.3	46.6	65.0	48.0	47.0	46.0	9.68	16.63
Sony 40VL130 (game)	2008	1080p	22.8	47.3	66.3	49.0	47.3	47.3	9.08	15.43
Philips 42PFL3603D/F7	2009	1080p	29.0	50.0	84.0	50.0	50.0	50.0	5.00	16.00
LG 42LC2D	2006	720p	28.3	50.6	54.6	50.8	50.4		6.30	15.95
Sony KDL-46EX400	2010	1080p	28.0	52.0	87.0	52.0	52.0	52.0	8.00	16.00
Toshiba 40L2200U	2014	1080p	30.0	56.0	74.0	56.0	56.0	56.0	10.00	16.00
Vizio E261VA	2012	720p	19.3	59.0	61.1	60.4	59.2	58.9	25.00	14.67
Samsung LN32B360	2010	720p	37.6	60.0	62.1	61.8	60.5	60.1	8.00	14.40
Samsung P2570HD	2010	1080p	37.0	62.0	62.0	62.0	62.0	62.0	10.00	15.00
Sharp LC-C3234U	2009	720p	33.0	64.6	83.6	66.6	64.6		15.00	16.60
Samsung LN46B610	2012	1080p	53.0	66.0	82.0	66.0	66.0	66.0	5.00	8.00
LG 42PT350	2012	1080p	63.5	67.7	85.9	68.9	67.7	67.7	4.20	0.00
Samsung LN46C630	2012	1080p	54.5	72.1	90.7	90.3	88.5	72.3	10.00	7.63
SANYO DP50749	2010	720p	67.0	75.0	103.0	94.0	79.0	75.0	7.00	1.00
Samsung HP-T4254	2011	1080p	69.7	75.7	94.1	76.0	75.7		5.00	1.00
LG 47LW6500-UA	2012	1080p	66.6	80.7	149.7	149.0	81.7	80.9	2.27	11.83
Vizio xvt4735v	2011	1080p	67.6	88.6	88.8	89.2	88.6	88.6	9.00	12.00

By that standard this TV is in the middle of my results from testing TVs and computer monitors. But when compared against TVs only, it actually is quite a bit above average. And, the ranking alone hides the fact that the faster TVs are not that much faster (at most about 16ms), and the slower TVs are way, way slower (up to 40ms). This is a solid showing from a company that to-date I considered to be a purveyor of generic and middling TVs. It's deinterlacing is also pretty good, using an adaptive algorithm that produces good looking results with only 16ms of extra lag.

Conclusion

If you really care about input lag to the exclusion of all else you can definitely do better with the right TV, and of course all TVs are completely crushed by their smaller cousins the computer monitor. But this is a sold reasonable choice and I would be perfectly happy to use it as my main gaming TV.

Other models

I tested the ELST5016s, which is the 50" version. There is also the  ELST4316s, which is the same specs but in a 43" size. Frankly, I expected more size options, but I didn't find anything else in the --16s line.

DIY webhook for logging shell command outputs to email

The idea here is to be able to run a shell command on a remote linux box and have the results sent to you via email. In this case the linux box doesn't have SMTP so I use a 2nd commercial server that does to operate a HTTP/PHP to email "gateway". This can't be abused for spam even if discovered since the destination is always fixed (a filtered folder in my Gmail account). 

On the linux box:

#!/bin/bash
# syntax hook <whatever>, if pipes used put quotes around it.
# sends user agent as command

echo $@
outp=$(eval "$@" 2>&1)
echo $outp
curl --user-agent "$@" -H "x:`echo "$outp"|gzip|base64 -w0`"  "https://sever.com/hook_URL/"

Replace server.com with your own webserver (not the linux box). The basic idea is to save the output of the command as gziped text that's been base64 encoded so that it's a valid http header (we use a custom header since these seem to be unlimited in size up to 8k, unlike the URL itself).

Then on the server make this php file inside /hook_URL/

<?php
$sender = "hook@server.com";  // sender address used to notify user
$receiver = "me@gmail.com";  // email address to send records to
$command = $_SERVER['HTTP_USER_AGENT']; // we store the command text as the agent

$raw = apache_request_headers()["x"]; // text from custom header

$text = gzdecode( base64_decode($raw) ); // convert from base 64 to binary and then gunzip it to ascii

mail($receiver, // where it gets emailed
	 $command, // title
	$text, // body
    "From: " . $_SERVER['REMOTE_ADDR'] . "_$sender", "-r $sender"); 
?>

then you can put in your cron or whatever:

hook "dmesg | tail"

you might ask why hook takes arguments rather than stdin; the reason is this way it can report what command was run rather than just the text sent to it via a pipe. Downside is you have to quote the command if it involves a pipe.

Guide: Improving raspberry pi SD card lifetime for remote servers

 Having built two  rPI NAS boxes, I've had a chance to see how well they survive in the wild. The answer: each one has failed within a couple years. 

The first one failed because the power supply was undersized. It worked fine for a while, but eventually the powered hub that served the pi and the external hard drive could no longer support both, which killed the hard drive being used. Solution: but an external hard drive that comes with its own power brick. It had better be enough if they include it in the box. 

The 2nd one failed due to SD card corruption. This can be caused by power issues as well, but I don't think that's what happened. I think the issue is that it was too small, and too old. As with all flash devices there's a limited number of times each cell can be written before they start to fail. On a small SD card the number of cells is likewise small, so there's less space to spread the writes out. I was using a 2gb card, which had enough space to fit a lite pi OS install, but didn't have much spare space left over. I didn't need extra space for building a NAS, but that limited space means that there wasn't room to do write leveling.

Beyond that, it's worth trying to reduce the amount of writes to the SD card so that you don't even get into the point that significant write leveling is need. 

Reduce swapping

Some people think you should eliminate swap all together, but doing that risks causing the out of memory killer shutting software down indiscriminately. Instead, let's reduce the amount of swapping that happens. Linux swaps memory to disk opportunistically in order to maintain extra free memory for immediate use. This keeps your computer more responsive, but some of that swapping will be unnecessary. Let's reduce that as much as possible.

echo vm.swappiness = 0 >  /etc/sysctl.d/00-swappiness.conf

Note this file probably doesn't exist on your computer(yet); the default value is 60, which you can check with cat /proc/sys/vm/swappiness . Note that zero doesn't turn off swap entirely, just reduces opportunist swapping.  You might try running top to see how much swap is being used before you change this value. Don't expect the value to go down until after you reboot. 

RAMDISK logs or reduced logging

Logs can be a constant source of disk access. One option is to store them in ram instead, but then you lose them with each reboot (I like to reboot every week) and logs can be useful for catching configuration problems or failing hardware.

SSH is by far the biggest source of writes, at least on a world-accessible machine. Every 2-3 seconds it writes a new message reporting the latest attempt of somebody to log into your machine (as root, of course) via SSH. You can see this for yourself: 

watch -d ls -l /var/log

In theory this is an important thing to log and keep track of, because OMG, somebody is trying to hack your machine!!! But in reality it's all automated sniffing from botnets around the world and is meaningless noise unless you are building a honeypot. I certainly don't want to wear out my SD card keeping track of it.

Rather than putting all logs in ram, I suggest two less severe mitigations. One is security via obscurity: change your ssh port. You will get a lot less traffic with any port that's above 1024. Or, you can turn off logs of authentication attempts all together, which is my preference. You'd think that editing

/etc/ssh/sshd_config  to include  LogLevel QUIET

would do this, but you still get some messages; you also need to instruct rsyslog to reject all messages from sshd by adding 

 :programname, isequal, "sshd" stop  as the first rule in   /etc/rsyslog.conf

But you are not done; you still get failed logins recorded to a binary file called /var/log/btmp. btmp exists outside the syslog framework, so you can't block it that way. The activity comes from openssh and can only be turned off by recompiling openssh! Yikes, what a dumb choice that is. There's a file system work-around though: you can make btmp immutable:

chattr +i /var/log/btmp

Finally, there's the systemd journal, which is the modern duplicate of syslog. That is to say both should have all the messages you care about in them, but you use different tools to search them. systemd journal has much less options for controlling what gets written to it, and I find that >90% of it is failed logins, even after the tweaks above.  Two options: make it volatile, (entirely stored in memory), or change the rate at which it's flushed to disk (default is every 5 minutes). These options are in /etc/systemd/journald.conf

It seems like by far the easiest option is to change your SSH port.

Stop recording access time

Linux records the last time files were accessed, so a regularly running system is going to incur some writes just from reading configuration files, etc.. There's already an /etc/fstab option that's the default on newer releases of PiOS to keep this to a minimum called noatime, but it's also suggested that adding norelatime would reduce the writes further. Might as well. 

LG W1953T review: input lag and upscaling using the piLagTesterPRO

This 1366x768 TN PC monitor from 2010 is typical for a TN display: very fast, with nearly no input lag, and a pretty good response time.

Image quality

Good upscaling is critical for retro gaming. Ideally, all pixels should appear equally sharp and bright (no aliasing), and angled lines should appear smooth, with no jagged, irregular steps. Also important is that the display shows most or all of the pixels it is sent. Often, this is not the case, with some number of pixels cropped from the bottom or top edges. Shockingly, these tests are relevant for modern gaming as well, because even at their native resolution many TVs have aliasing and cropping. Monitors tend to show all pixels and never crop, and thus have fewer scaling options.

This monitor has no scaling or cropping options. All you can do is force 4:3, otherwise it always scales so that X and Y fill the screen completely.

resolution	aliasing/jaggies
480p	very minor jaggies, A- overall
720p	noticeable aliasing, B
1366x786	native resolution, pixel perfect
1080p	not supported

The display has 1 VGA and 1 DVI. I only tested DVI (over a passive HDMI converter).

Input Lag

I used a piLagTesterPRO to measure input lag. This device sends a frame of video over HDMI and measures how long it takes to display it. This display does not have a game mode; I toggled all the display quality settings and did not see a consistent effect on lag, however the tests reported are with every "enhancement" set to off.

I report two kinds of values. 1st response measures how long it takes for the TV to start responding (I use a 5% change in display brightness). This overly optimistic value doesn't tell how long it takes to see anything useful, but matches what other reviewers call input lag. full response is a more realistic measure of lag, and requires the display to reach 80% of full brightness. This combines both input lag and response time, and is closer to what you would actually experience in a game.

	top		bottom
Resolution	1st (average)	full response	1st response	full response	scan out
480i	N/A
480p	3.4	13.4	18.7	28.7	15.3
720p	2.6	12.6	18.7	28.7	16.1
1080p	N/A
1366x768@70	2.5	12.5	16.4	26.4	13.9
1366@768@75	2.5	12.5	15.5	25.5	13.0

This display does not support interlaced modes at all. It also doesn't support 1080p. But it does support 70hz and 75hz in addition to the standard 60hz we all know and love.

The first response at the top of the screen was slightly slower for 480p, otherwise it averaged 2.5ms across all resolutions and refresh rates. The 1st response at the bottom of the screen did not depend on resolution, but did depend on refresh rate, as you would expect. The scan out at 60hz was about 16ms, which is about 1/60th a second. Raising the refresh rate to 70hz shaves 1ms off that, and raising it to 75 shaves off another 1ms on top of that. So if you want the lowest input lag overall definitely run at 75hz.

Interestingly the display does not advertise supporting 75hz at the native resolution (only 60hz), so you have tell your video card to force that mode. I saw no problems running it in this mode, however, and the monitor redraw always stayed locked vsync, with no glitches or drifting lag.

The response time of the display averages 10ms. The spec sheet advertises 2ms, which is just a bald-face lie, but is true that you can get the response time down to about 5ms, depending on the transition the LCD has to make. Black to white is fast and fairly clean, whereas other transitions can happen in a 2-step process where the LCD gets close to the desired brightness, pauses for a couple ms, and then steps the rest of the way. I'm sure this two-step process causes some motion artifacts when viewed on a high speed camera, and probably results in moving stimuli looking more muddy to the human eye than they would otherwise. I'm not going to be too hard on the display, however, as this is a common issue.

Results compared to other displays

To allow quick comparison between many displays I've summarized the results across all the displays I've personally tested with the piLagTester Pro. Min lag is the time to the first response, measured where the screen starts drawing (typically, the top); real lag is the time to the full response, measured where drawing finishes (usually the screen bottom), i.e. input lag + scan out + response time. Numbers in red denote average values that can vary by up to 8ms between power cycles.

This list is sorted by real lag for each display's native resolution and max refresh rate (usually 1080p60 but some sets are 720p60, and other monitors like this one support > 60hz).

 

Display	Year made (TV?)	Native Res	native min lag	native real lag	480i real lag	480p real lag	720p real lag	1080p real lag	native response time	native scan out
Dell E198FPb	2008	1024p	2.7	20.4		39.0	35.0		5.00	12.70
Samsung 2494sw	2011	1080p	2.8	22.7		26.5	26.5	26.5	8.00	13.30
Vizio VO370M	2010	1080p	2.5	23.6	83.0	49.0	47.0	24.3	5.47	15.67
LG W1953T	2010	768p	2.6	25.6		28.7	28.7		10.00	13.00
Dell U2410 (game)	2010	1080p	4.0	26.2	62.2	28.3	26.5	26.5	6.00	16.20
TCL 40S325	2021	1080p	6.5	27.3	60.6	29.0	27.9	27.7	6.00	14.83
TCL 49s403	2018	4k	6.1	30.2	76.8	30.9	30.3	30.7	8.00	16.13
AOC/Envision G19LWK	2010	900p	3.1	31.2	39.5	38.7	38.4	37.8	15.50	12.60
Dell E2211H	2014	1080p	3.0	33.6	34.7	34.5	34.1	33.8	15.00	15.57
Dell 1907FPc	2008	1024p	3.0	34.0		35.9	34.8		15.00	16.00
Panasonic TH-58PE75U	2008	720p	28.0	34.0	34.0	34.0	34.0	34.0	6.00	0.00
Panasonic TH-42PX75U	2008	720p	28.0	34.0	34.0	34.0	34.0	34.0	6.00	0.00
Panasonic TH-50PZ80U	2008	720p	28.0	34.0	34.0	34.0	34.0	34.0	6.00	0.00
Corprit D157 (hdmi)	2021	1080p	3.1	34.5	34.9	34.8	34.6	33.9	16.25	15.13
Samsung S27C230	2014	1080p	2.9	36.0		36.6	36.1	36.1	18.10	14.97
Vizio E470VL (vga)	2011	1080p	22.0	39.0		39.0	39.0	39.0	9.00	8.00
Samsung LN32D403	2012	720p	20.9	41.2	58.9	42.4	40.7	40.7	5.50	14.83
TCL50s423	2021	4k	14.0	42.0	75.0	42.0	42.0	42.0	13.00	15.00
Dell U2410 (sRGB)	2010	1080p	20.5	42.8	62.4	45.0	43.1	43.1	6.13	16.13
ACER AT3265	2012	1080p	19.5	43.8	62.7	45.3	43.8	43.8	8.00	16.27
sony XBR 43X800D	2017	4k	24.5	44.3	46.5	46.0	44.6	44.7	5.00	14.83
RCA L40FHD41	2010	1080p	20.3	46.6	65.0	48.0	47.0	46.0	9.68	16.63
Sony 40VL130 (game)	2008	1080p	22.8	47.3	66.3	49.0	47.3	47.3	9.08	15.43
Polaroid FLM-373B	2007	720p	28.0	49.0	82.0	49.0	49.0	49.0	7.00	14.00
Philips 42PFL3603D/F7	2009	1080p	29.0	50.0	84.0	50.0	50.0	50.0	5.00	16.00
Sony KDL-40V3000	2008	1080p	22.2	50.1	68.4	50.6	50.5	49.8	11.00	16.93
LG 42LC2D	2006	720p	28.3	50.6	54.6	50.8	50.4		6.30	15.95
GPX TDE3245W	2016	720p	28.0	51.0	102.0	51.0	51.0	51.0	8.00	15.00
Sony KDL-46EX400	2010	1080p	28.0	52.0	87.0	52.0	52.0	52.0	8.00	16.00
Toshiba 40L2200U	2014	1080p	30.0	56.0	74.0	56.0	56.0	56.0	10.00	16.00
Vizio E261VA	2012	720p	19.3	59.0	61.1	60.4	59.2	58.9	25.00	14.67
Emprex HD 3202	2007	720p	27.0	66.0	126.0	51.0	50.0	62.0	24.00	15.00
Samsung LN32B360	2010	720p	37.6	60.0	62.1	61.8	60.5	60.1	8.00	14.40

Thus sorted this display finds itself near the top of my list, but that's largely because most of my list is TVs (in fact I've discarded the slowest 3rd of my list to keep the length manageable). Computer monitors (particularly TN) are known to be very fast, and this one is no exception. It would be more impressive if it were an IPS screen (such as the Dell U2410, which is nearly as fast, just one spot down on the list). The real take away is that any TN computer monitor will have great lag, and that any PC IPS display, while slower than TN, will still beat the pants off the TVs.

Similar models(?)

I tested the w1953T, which is the 19" version.  There does not appear to be a larger version that is precisely identical. The LG W2053TQ is also a TN display but has 1600x900 resolution. The W2253TQ  is full HD (1080p). But all 3 are TN displays from the same era, so at the least you can assume they have good input lag, and if the model number alone is meaningful, identical lag to this one. The W2453V is an IPS display and thus is almost certainly slower than these displays.