The Lenovo Thinkpad X61 tablet has a “12.1-in Super Wide Angle SXGA+ TFT display with 1400 x 1050 resolution” option. The display panel is the BOE-Hydis HV121P01-101, an AFFS display with glass bonded to the LCD panel. The predecessor used in the X60 tablet (HV121P01-100) uses the same LCD panel but did not bond the cover glass to the LCD.

The display is prone to developing bubbles in the adhesive layer in between the LCD and glass. There’s a long thread at Lenovo forums (Air Bubble In LCD Screen X61 Tablet) about the bubbles and the difficulty of getting it replaced or repaired.

Pictures

Air bubbles appearing near the bottom edge of the display.

More air bubbles.

This picture shows a new bubble forming inside an existing bubble. A new bubble would emerge every few days. The buttons below the display were also sticky from the leaked adhesive.

The bezel was sticky. This is the adhesive from the LCD, not the double-sided tape melting. It was gooey only along the bottom edge where the LCD adhesive was leaking.

To see what’s going on inside, the bezel was removed. There was a lot of leaked adhesive, especially along the bottom-left edge. It appeared as though the adhesive was being wicked out of the bottom edge of the LCD by adhering to and flowing along the plastic bezel piece, gumming up the buttons. Air bubbles entered to replace the loss of adhesive.

The most obvious repair method is to apply heat and pressure to squeeze out the air bubbles, with enough heat to redistribute the adhesive evenly across the entire display (resulting in a slightly thinner adhesive layer). That didn’t work: I successfully squeezed out the air bubbles, but the heated adhesive did not behave like a Newtonion fluid (non-zero shear stress at rest), so it tended to flow back to its original position, refusing to be evenly redistributed.



Some adhesive was lost during the repair attempt, there was continuing leakage out the bottom, and the adhesive refused to flow, so even more air was drawn in to replace the adhesive deficit along the bottom edge. This resulted in even more bubbles after the repair attempt.

This is the current state, after a second repair attempt using higher temperatures, also failing in the same way. I’m hoping I can get some fresh adhesive (of the same kind) to fill in the (big) bubble, since it seems hopeless to try to redistribute the existing adhesive.

Which Adhesive?

There are many suppliers for optical adhesive:

• Dymax
• Norland
• Summers Optical
• 3M
• DuPont Vertak
• Henker Loctite
• Hernon Ultrabond

The X61 tablet uses a Hydis HV121P01-101 screen, the same as those found in a Motion Computing LE1700 tablet. Motion Computing advertises later Hydis displays using DuPont Vertak bonding, so there’s a good chance the older Hydis HV121P01-101 also uses a DuPont adhesive (Vertak DBA1000/2000 or a predecessor?).

The Vertak adhesives have low elastic and shear modulus and strength, which might contribute to its tendency to flow out the side of the display. Qualitatively, the gooey adhesive I see in my display agrees with the properties listed in the datasheet.

Repair?

I think I can make a decent repair of the bubbles by filling in the bubbles with fresh adhesive (ideally of the same kind), curing it, and then sealing the edge of the display with silicone to prevent future adhesive leaks. I don’t have a clean room, so I’m not able to completely replace the adhesive without getting dust into the display.

Chair frame without seat.

Front corners are high-stress points that crack. This one has already been welded back together (welded from the back, so the weld isn’t very visible.)

Back side also glued with polyurethane glue. Almost nothing sticks to polypropylene, so the glue might peel once it’s back in use… We’ll see if it’s good enough.

The plastic is scored with a knife to make a rougher surface so the glue might hold better.

Next step: Reinforce the weak spot using some fiberglass window screen soaked in epoxy. Or maybe epoxy-polyurethane mix. Something mostly rigid, but not so hard that it cracks when flexed slightly, hopefully.

Fibreglass window screen partially glued with a bit of epoxy.

Window screen covered with epoxy.

Update

Two months later, the crack hasn’t spread. Cosmetically, the crack is visible. Structurally, the repair seems good enough.

Parsers

I also tried Wiky (Ruby), WikiModel 2.0.6 (Java), and libmwparser. These crashed on some of the test documents…

Although this was intended to be a comparison between programming/scripting languages, the data isn’t really valid for this purpose. The algorithms between parsers, the subset of the language syntax it supports, and the correctness of the output varies between the parsers. Draw your own conclusions…

Test documents

I just chose a bunch of mostly-random documents (using Special:Random) that exercised various features of the language (short/long documents, tables, images).

• Agasanahalli (Dharwad) (1,587 bytes, a short article)
• Predicted outcome value theory (11,331 bytes, mainly text)
• Eurosong ’06 (12,186 bytes, lots of tables)
• Automobile (49,471 bytes)
• Mediawiki (80,149 bytes)
• List of tallest buildings in New York City (81,648 bytes, more tables with images)
• Nuclear program of Iran (292,201 bytes, a long article)
• The Young and the Restless minor characters (386,012 bytes, a long article)

Results

Geometric mean of runtime over all 8 test documents for each parser

It’s not surprising that MediaWiki’s parser is the slowest of the bunch. It’s written in a scripting language (PHP), is the most feature-complete, and doesn’t use fancy parsing algorithms. PHP5 Wiki Parser is probably faster because it processes only a small subset of the syntax. As far as I know, a few of the others are in production use: xWiki (parser in xWiki), WikiText (MyLyn), and Kiwi (parser used on aboutus.org). Flexbisonparse stands out as being particularly fast (113x!), and it would be interesting to see whether it can robustly support a sufficient subset of the MediaWiki syntax in production without giving up all its speed. Flex and Bison are both around 25 years old, yet they’re both still alive and well.

Normalized parser runtime by document

Here are some normalized runtimes broken down by document. The objective is to show whether certain parsers have particular strengths for particular document types. The data are normalized to the parsers’ geomean runtime so the geomean for each parser is 1. The data are also normalized by document so that the geomean for each document is also 1. The relative runtimes appear quite random: none of the parsers seem to scale particularly well or poorly with document length.

• ML-1740
• ML-2010

Ever since upgrading from Mandriva 2010.0(?) to 2010.1 (and also 2010.2), both printers have been intermittent. Print jobs would often be silently discarded. CUPS logs show that the print jobs are completed, the printer would warm up, the printer’s LED blinks once or twice, then the print job is “complete”. But nothing gets printed. Unplugging the USB cable will allow printing at least one print job, but sending usb_clear_halt, a printer class SOFT_RESET, nor usb_reset() will get the printer to work.

Since the same behaviour occurs for both printers, and started at the same time (after an upgrade), it’s probably not a random hardware failure.

The symptoms are similar to some posts out there:

• CUPS – can’t seem to print more than one page (ML-2010, libusb, Arch Linux)
• Print jobs intermittently corrupted (Several Samsung printers, Mandriva 2010.2)
• Printing from Windows 7 to shared printer on Ubuntu 10.10 – Completed but no print! (ML-2510)
• Samsung CLP-315 problem on Mandriva 2010.1 (CLP-315, using libusb)
• CUPS STR #3964 (Several printers using libusb, Ubuntu)

The common thing in all of these seem to be printing with CUPS using libusb with a Samsung printer (Mandriva removed usblp somewhere around 2010.1). Indeed, the Archlinux thread suggests that moving back to usblp printing solves the problem.

After tons of debugging, the problem appears to be a problem (flaw?) with Samsung’s firmware interacting with some behaviour in the CUPS USB (usb-libusb.c) backend. Hint: usbmon with Wireshark is very useful for capturing USB traffic.

In the current USB (usb-libusb.c) backend, a typical print job performs the following steps:

1. Loops through all USB buses, devices, configurations, and interfaces, to look for USB printer class interfaces, sends a printer class GET_DEVICE_ID request to it, and tries to find the desired printer based on the returned string.
2. Opens the device (usb_open)
3. Sends a Set Configuration request to the device to set it to the desired configuration. (usb_set_configuration)
4. Claims the desired interface (usb_claim_interface)
5. Sends a Set Interface request to the device to choose the desired interface. (usb_set_altinterface)
6. Dumps the print data in 8,192-byte chunks in one or more(?) USB bulk transactions using usb_bulk_write
7. Releases interfaces that were claimed earlier (usb_release_interface)
8. Close the device (usb_close)

On my printers (and I expect most other printers too), steps 3 and 5 aren’t really useful. There is only one configuration (bConfiguration=1) and only one interface (bAlternateSetting=0) for that configuration. Normally some part of the OS already sends a Set Configuration to put the device into the Configured state (see USB spec) when the device is plugged in, so there is no real need to again set the configuration to the current value. Similarly, if there is only one altsetting, it is the default and there is no real use to setting it.

According to the USB spec, the above sequence of operations, including setting the configuration and altsetting after the device is already configured, is legal. However, it seems like my Samsung printers do not want to see steps 3 and 5 happen, even though the printer returns a success return code for those requests. It is the presence of the redundant Set Configuration and Set Interface requests that appear to cause the subsequent print job to sometimes/usually be silently discarded. Removing both those requests causes the printer to behave normally.

It appears usblp’s print sequence is much simpler: It sends a GET_DEVICE_ID to the printer, then dumps the print data to the printer using a USB bulk transfer. It does not set configuration or interface, perhaps (correctly) assuming that it was already done when the printer was first enumerated by usblp. This difference would explain why CUPS-usblp works fine but CUPS-libusb does not. However, since both CUPS-usblp and CUPS-libusb follow the USB spec, it’s likely Samsung’s firmware that is flawed here.

One way to work around the probelm is to simplify CUPS’s usb-libusb backend to not send Set Configuration or Set Interface requests when it’s not necessary. Samsung printers don’t seem to have a problem with Get Configuration requests, so I first query the current configuration, then change configurations only if the desired configuration is different from the current one.

Upstream

Submitted to CUPS as STR #3965.

Downloads

• Patch: cups-1.4.3-usb-skip-interface-altsetting.patch. For Mandriva 2010.2 cups-1.4.3.
• Patch: cups-1.6-r10087-usb-skip-interface-altsetting.patch. For cups-1.6 svn r10087.
• Binary RPM for Mandriva 2010.2 x86_64: cups-1.4.3-3.2mdv2010.2.x86_64.rpm
• Source RPM for Mandriva 2010.2: cups-1.4.3-3.2mdv2010.2.src.rpm

Speedtest.net Numbers

The speedtest.net numbers were measured using the same DSL line (different logins) using the Nexicom server, which is even closer through Teksavvy’s routing than Bell’s. This is the average of many tests over two days, with average and standard deviation of the results posted here. This is using an MTU of 1485, which works around all of the fragmentation issues. Multilink performs noticeably worse than the others.

Packet Loss and Fragmentation

Teksavvy negotiates the following options over LCP:

• MRU 1492
• MRRU 32719

This is a plot of packet loss rate vs. PPP frame size. With a large MRRU, the upstream direction consists of a single large ICMP echo request packet encapsulated into a single large PPP frame, then fragmented at the PPP layer into multiple MLPPP frames. In the downstream direction, Teksavvy does not fragment PPP frames, but fragments the IP packet with each fragment in its own PPP frame. MLPPP frames not greater than 1485 bytes are not fragmented. With MRRU > MRU, we can experiment with both PPP and IP fragmentation.

The periodic spikes in packet loss are abnormal. The spikes correspond to packet sizes at which the ICMP response packet is slightly larger than a multiple of the IP MTU, so there is a small fragment left over after fragmentation. It is the presence of these small fragments that cause packet loss.

Reordering PPP frames causes packet loss

The MLPPP session violates RFC 1990 Section 4.1 by delivering PPP frames out of order. When a large packet followed by a tiny fragment, the PPP frame containing the small fragment often arrives sooner than the PPP frame containing the preceding large fragment. RFC 1990 forbids out of order MLPPP frames, so the only choice is to discard frames that arrive out of order, which causes the observed “packet loss”.

The same symptoms occur in both upstream and downstream directions, regardless of whether the small frames originated from IP packet fragments or PPP frame fragments. The reordering happens at the PPP layer: The IP fragment offsets are in-order relative to the MLPPP sequence number. It appears this PPP frame reordering is done by Teksavvy: Using the same DSL line, modem, and configuration, a Teksavvy login will reorder small packets ahead of a big one, but a Bell DSL login will not.

With plain IP on PPP (no PPP multilink, compression, nor encryption), this isn’t a huge issue. PPP doesn’t notice when packets are out of order, and IP doesn’t care. Out of order packet delivery breaks everything else, however.

For MLPPP, I think other than getting the PPP layer to deliver packets in order, the next best thing is to avoid creating tiny frames to reduce the probability of getting a reordered packet. Reducing fragmentation should help, but it probably won’t help if tiny ACK packets are being reordered too. MLPPP requires that the underlying PPP frames are delivered in order as RFC 1661 requires: mostly-in-order isn’t sufficient.

It looks like this might be an attempt to improve performance by prioritizing small frames (likely to be ACK packets). But the PPP layer would be the wrong place to do this.

Reducing fragmentation via MRU/MRRU options

If the network will deliver tiny MLPPP frames out of order, we can avoid some of the penalty by reducing the number of small frames. We can’t affect how many small IP packets (and empty ACKs) are sent, so the best we can do is avoid IP or PPP fragmentation.

There are two significant sources of fragmentation: Downstream IP packet fragmentation, and upstream PPP frame fragmentation. It appears Teksavvy’s router does not do downstream PPP frame fragmentation, and upstream IP fragmentation should be rare if Path MTU detection works normally.

Upstream

1. On single-link bundles, when MRRU > (MRU – headers(6 bytes)), large PPP frames are fragmented to fit in the MRU. Since the MRRU is used as the IP-layer MTU, PPP frame fragmentation can be avoided by lowering the server MRRU to (1492-6 = 1486), keeping MRU at 1492.

   Workaround: Set the client IP-layer MTU to 1486 manually to avoid upstream PPP frame fragmentation.

2. Additionally, the Linux kernel (2.6.31-rc6 and newer) seems to have a bug where it fragments PPP frames into MLPPP fragments 2 bytes smaller than allowed by the MRU. (drivers/net/ppp_generic.c: ppp_mp_explode()) Lowering the server MRRU (or client IP MTU) to 1484 may be even better.

Downstream

3. It appears the client’s MRU is used incorrectly by Teksavvy’s router. The MRU value should apply to the PPP payload, but Teksavvy’s routers appear to use it for the IP layer’s MTU without subtracting off the 6-byte multilink headers. Because of this, Teksavvy’s routers will send PPP frames that are up to 6 bytes longer than the client’s MRU. The routers handle the MRRU option correctly. Normally, the client MRRU is used for the IP MTU and the PPP layer will fragment frames to fit within MRU, but Teksavvy does not fragment PPP frames.

   Workaround: At least one of the routers (206.248.154.106) seems to have hard-coded a maximum IP-layer MTU of 1486. Otherwise, the client MRRU should be set to 1486 (with MRU=1492).

   • Teksavvy’s workaround has a side effect when multilink is disabled. When the MTU is really 1492, the router fragments IP packets at 1486 anyway.
   • This IP-layer fragmentation ignores the don’t-fragment DF bit. This breaks Path-MTU discovery.

     To Teksavvy: I think the DF bit should be respected, but this might make bad
     configurations fail even harder.

4. There is no hard-coded 1486-byte IP-MTU on 206.248.154.103. Workaround: The client should ask for a 1486-byte MRRU because the 1492-byte MRU option is handled incorrectly.

Summary

Client:

• Set IP-MTU to 1486 (or 1484 on Linux 2.6.31+) to avoid upstream PPP frame fragmentation (#1)
• Set MRU=1492. This is the correct value even though Teksavvy doesn’t handle it correctly.
• Set MRRU to 1486 because Teksavvy does not correctly handle a MRU of 1492. (#2)

Teksavvy:

• Setting server MRRU to 1486 (or 1484 for Linux clients) would avoid upstream PPP fragmentation without the client manually setting his MTU. (#1)
• MRU should be 1492 as it is now.
• Hard-coding IP-MTU to 1486 bytes is a good workaround for MLPPP use, but not so good for non-MLPPP users who want IP-MTU=1492, but please respect the DF flag! (#3)

Currently, Intel uses HT as a feature for market segmentation: The desktop Core i5 processors differ from the Core i7 mainly by whether HT has been disabled, and Intel charges a significant price premium for the Core i7. Therefore, I want to know what the performance benefit of HT is. Since my workloads usually involve running many independent single-threaded processes on a cluster of machines, these measurements don’t use multithreaded workloads.

Hardware

Workloads

Throughput Scaling with Multiple Threads

With the exception of the kernel compile workload, all of these tests start multiple instances of the same task and measures the total throughput of the processor (number of tasks/average runtime for task). Kernel compile uses “make -j” to run multiple instances of GCC to independently compile each file, and the time to compile the entire kernel is measured.

The number of simultaneous tasks are varied and plotted. For workloads that are not memory-bound, we expect roughly linear improvement in throughput between 1 and 4 threads (for a 4-core processor), less improvement between 4 and 8 threads (the additional benefit of HT), and roughly no change in throughput beyond 8 threads (these tasks have little IO).

This line plot shows all of the data in one plot. The workload throughput scales reasonably close to linear with the number of real cores they use (1 to 4 threads), while throughput improvements due to HT vary between workloads. Interestingly, Dhrystone throughput decreases with HT, while CoreMark has the second-highest gain (behind VPR), yet both of them are small integer benchmarks that have little main memory traffic.

Hyper-Threading Throughput Scaling

This chart focuses on comparing the throughput at 8 threads vs. 4 threads for the different workloads. The median improvement for HT is 25%.

Multicore Throughput Scaling

This plot compares the throughput at 4 threads (1 thread of each core used) vs. 1 thread. If independent processes are executing on independent cores, we would expect to see 4x improvement in throughput when running 4 copies of the workload. In the Core i7, the L3 cache and memory system are shared between cores. Scaling less than 4x with 4 independent threads indicates that the workload is sensitive to L3 cache size or memory system bandwidth.

Note that the kernel compile workload isn’t strictly independent, so sub-linear scaling does not necessarily mean GCC is sensitive to cache size or memory system bandwidth. The kernel compile workload compiles different files in parallel, with some dependencies between tasks.

Most of the workloads scale close to 4x with 4 cores. Other than kernel compile, Quartus and GPGPU-Sim workloads scale significantly worse than linear. Quartus is known to be sensitive to memory performance. I don’t know about GPGPU-Sim’s characteristics, but this might be a hint that it, too, has fairly random access patterns on a large memory working set.

Core i5 or Core i7?

The above measurements were made using a Lynnfield Core i7, but future purchasing decisions would be for the next-generation Sandy Bridge. It is unknown how closely the performance gains for HT on Sandy Bridge processors match the HT gains for Lynnfield, although I would expect them to be similar.

As of today, a Sandy Bridge Core i7-2600K costs around $300, while a Core i5-2500K costs $210. The system cost is around 22% higher for the Core i7-2600K assuming each node has the same amount of RAM (so memory/thread is half on the HT system compared to the non-HT system). This indicates that price-performance is slightly higher for Core i7 with HT (22% more price for 25% more performance) when running cluster-type workloads. However, because price-performance is so close, there are other issues to consider:

• Hyper-Threading requires twice as many threads to achieve peak CPU utilization, requiring each system to have twice the amount of RAM to keep memory/thread constant. Cluster-type workloads run independent processes that don’t share memory, so memory consumption is nearly linear with the number of threads. Doubling the RAM for a HT system further adds to the system cost.
• Hyper-Threading creates the potential for load imbalance, where one node has more tasks than physical cores (is using HT) while another node has physical cores idling. This is the same scheduling problem as discussed in my post on SMT-aware process schedulers, but extended to scheduling between different compute nodes. This could be significant for long-running jobs, although with 4C-8T, the likely impact of this should be small (Probability theory escapes me for the moment, I don’t know how much).
• Hyper-Threading should be a net power-performance win. HT does consume significantly more power when used, but I believe it’s less than 20%. Will need measuring.
• Although a net power win, HT CPUs have higher power density and are harder to cool. For temperature-limited overclocks, a non-HT CPU will likely clock slightly higher, even if total system power is higher.
• Hyper-Threading is a performance-density win, because the alternative of having more nodes in a non-HT cluster occupies more space, even if it doesn’t cost more.

Conclusion: I still don’t know…

The default process scheduler in Linux (as of kernel 2.6.34) is CFQ (Completely Fair Queuing). The “tmb” series of kernels optional in Mandriva distributions come with the BFS (Brain Fuck Scheduler) as default. BFS claims to be SMT-aware, much simpler, and lower latency than CFQ, targeted for “interactive” desktop-style use on small systems.

Here, I measure how “SMT-aware” the BFS and CFQ schedulers are at running a simple CPU-intensive workload.

Workload

Dhrystone 2.1 compiled for x86-64 with gcc. This is a simple integer benchmark that has a small memory footprint and no I/O. I run multiple independent instances of Dhrystone at the same time. Interestingly, Dhrystone’s throughput actually falls with hyperthreading, by roughly 4% when running two threads compared to one.

System

• Core i7 860. 4 cores, 2-way SMT
• Mandriva Linux, kernel-tmb-server-2.6.34.7-3mdv. BFS and CFQ process schedulers.

CFQ and BFS

When scheduling threads to cores and thread contexts, there are three trivial cases (for N thread contexts): One runnable thread (placing it on any thread context is the same), and N-1 runnable threads (leave exactly one thread context idle, which one doesn’t matter), and N or more threads (fill every thread context, and rotate between them fairly). With several threads, the ideal scheduling is to first give each thread its own core, and then double up (use both thread contexts on a core) when there are more threads than cores. The “Manual Affinity” option below manually assigns Dhrystone tasks onto processors using this rule.

Both CFS and manual affinity perform the same. On a 4-core, 8-thread system, Dhrystone performance increases linearly when up to 4 instances are run. Beyond 4 instances, throughput drops slightly until 8 instances since Dhrystone performs worse with SMT than without. Most other applications would see a shallow upward slope and gain an extra 15-25% throughput between 4 and 8 instances.

BFS bounces the tasks around different thread contexts and often gets the scheduling wrong, leading to lower performance between 2 and 6 instances. Not good.

Is BFS SMT-Aware?

If BFS isn’t very good at scheduling for multicore SMT systems, we should ask whether BFS is SMT-aware at all. I compare BFS to a hypothetical random scheduler that randomly assigns threads to thread contexts. The plot is calculated using straightforward probability, assuming a thread runs at full speed when running alone on a core and gains no additional throughput from SMT (which is slightly better than Dhrystone’s -4%), then scaled to match the graph. The Manual Affinity results are also plotted for comparison.

The graph shows that BFS is indeed SMT-aware. It achieves performance roughly halfway between the ideal scheduling and a random scheduler. It’s just not very good at fully utilizing all the cores before allowing threads to double up onto one core.

Ubuntu 10.10 and Core i7 980X

Out of curiosity, I ran the same test on a 6-core, 12-thread Core i7 980X overclocked to 4.22 GHz.

The Manual Affinity and CFQ plots are normal between 1 and 4 Dhrystone instances (linear increase), but performance is abnormally slow at 5 or more instances. Reason: The processor exceeds 100°C and is being throttled.

Power supplies usually use single-layer circuit boards, making reverse-engineering the circuit possible. It is interesting the power supply uses entirely discrete devices using two bipolar PNP transistor to implement fan speed control.

A TTC103 negative temperature coefficient thermistor is used (10k at 25°C, 2.5k at 60°C, 1k at 85°C). The circuit appears to use both the output voltage as negative feedback and the thermistor voltage to set the output current that controls fan speed. The diode is probably used to ensure the fan spins even at low temperatures.

The first (left) PNP transistor failed, and leaked current from the base to collector. This caused enough emitter-base current to turn on the fan even when the base voltage is high. The failed transistor was replace with a TO-92 PNP transistor (BC327). Surface mount components are hard to solder…

Being curious how the fan speed control circuit really behaves, I simulated it using LTspice. The fan is modeled as a 100 ohm resistance. Output voltage and the thermistor voltage are plotted against thermistor resistance. Thermistor resistance is non-linear (roughly 10k at 25°C, 1k at 85°C). The temperature at which the fan speeds up can be adjusted using the 6.8k/36k divider and is strongly dependent on the forward base-emitter voltage of the transistors. Two BC327 transistors are simulated because I can’t read the marking on the transistor. The circuit creates a nice speed vs. temperature curve, with a reasonably linear transition region (55°C-95°C) and still keeping the fans on (27mA) at low temperatures.

The new refrigerator uses 38% of the electricity of the old one, while also being 20% bigger. Assuming $0.10/kWh, the new refrigerator saves $36.40/year. Both refrigerators use about 70% of their rated consumption.

Test Methodology

This is data from a 2003 Corolla CE, collected between Jan. 2009 and Nov. 2010. Each data point is the fuel efficiency for one tank of gasoline at the time of the refueling. The trips consist mostly of a mix of highway and city driving with about 60% highway by time traveled. Data points from long highway-only trips have been removed. The month and day of the fill-up is plotted, with the year ignored, so the resulting graph is cyclical with a period of one year.

Results

There is a noticeable seasonal dependence of fuel efficiency, and is correlated with average temperature, being worst in mid-January. Winter vs. summer fuel efficiency differs by about 15%, but there is also significant random variation of comparable magnitude between fill-ups. I don’t see evidence that the use of air conditioning during the hottest summer months has a big impact on fuel efficiency.