Post #27106

Signature not verified

This entry might be using an old signature, or it was signed by a key that does not exist on the server.

The entry content as it exists in the database. This should be verified against the blockchain entry.
Maxing out a Factom network
Thanks for providing a thorough analysis (as always)

[QUOTE="Who, post: 27083, member: 192"]
Not necessarily. Golang channels are kinda tricky and due to the cooperative scheduling, I found that some channels are just not being worked off "correctly", meaning channel A will drain completely even though channel B has a much larger pile waiting. In practice, this resulted in some of the non-blocking channels overflowing when they shouldn't.

I guess hunting for channels that are being starved for work while others are overflowing would be one symptom we could look for.

Sort of depressing that this doesn't feel like a new line of investigation - essentially this is what has been done repeatedly since m3 was first released.

[QUOTE="Who, post: 27083, member: 192"]
At some point, I'd like to get a full message dump (both send and receive, and not just app messages) for proper analysis. It would also be great to test the p2p network independently of the factomd code, which would test the theory of whether I/O is the limiting factor or not.

My notion about IO is pretty vague - I'm not thinking Disk or Memory IO but more systems-level interrupts etc..
This actually may just be about Golang/channel scheduling as you say.

Seeing a p2p max (without troublesome factomd code) would be an interesting data point.
This is the raw content, without BBCode parsing.