I controlled some variables and the problem still persisted.
I set still client that is still bootstrapping to connect=192.168.1.100, that being the static local address of another computer running a full node. It certainly pulled in the blocks fast, at about 1 MB/s. That only for three minutes or so before the sync ground to a halt. I restarted the program, and sure enough, another solid run of data transfer, maybe for six or seven minutes, then it stopped.
Here is a graph of my CPU. It shows about 30 minutes of history. Bitcoin was the only thing running. I quit the program twice and restarted twice over the course of the graph. It let the computer idle for a minute in between. Starting from the left, about 20% into the graph, there is a short lull, followed by the biggest chunk of CPU thus far. That was when I restarted the client. Then there is a break in CPU effort, after the client has started, but before it was crunching blocks. Then there is a period of block processing, before it reverts to a very low intensity state, with not much syncing.
After ~8 minutes of mostly idling, I restated again (the middle point of the graph). The same pattern repeats, though this time it processed blocks for ~7 minutes or so.
I even unplugged the WAN cable. Each client showed one connection, one outbound, one inbound. They were just talking to each other. Again, the syncing went fast for a few minutes, then mostly stopped.
I have seen basically the same behavior just running the client stock, connecting to larger bitcoin network, and running it modified, to only connect to local hosts.
