Bench-tps depends too much on forwarding and floods the network

[garious]

Problem

Client code doesn't know what node will be the leader by the time its transaction arrives and so depends on validator forwarding to get the transactions to the right place. To make matters a little worse, the validator isn't much smarter and assumes zero network latency. That can cause infinite forwarding as each transaction arrives a hair too late and needs to be forwarded again.

Proposed Solution

• Filter out late transactions using the transactions HashQueue and the transaction's recent_blockhash
• Add counters so we can see how often we're missing those windows
• Add logic to validators to acknowledge network latency when choosing to forward transactions
• Add an RPC API endpoint such that the client can get more information regarding where it should send its transactions
• After a bit of discussion, split the above into separate tickets.

[pgarg66]

#4266 #4249 #4199

[pgarg66]

Most of the items discussed in this issue are done. The outstanding item is
Add an RPC API endpoint such that the client can get more information regarding where it should send its transactions

Wondering if we should indeed be doing this, given the frequency of the leader rotation. The client may not catch the current leader with certainty.

[pgarg66]

@garious any thoughts about my previous comment?

[garious]

@pgarg66 Sounds great! Yes, agreed on punting on the RPC endpoint suggestion. That idea predates the more ambitious (and higher TPS!) plan of sending transactions to the nearest validator, letting it batch transactions, and then sending large batches to the leader.

[pgarg66]

Thanks @garious , I'll close the issue then.