そもそも、どの程度の精度を求めていますか？
各回に送出されるデータ長がどの程度のサイズで、それがどの程度の時間間隔で発信されるのか。
そして画面側への反映頻度は、その送信頻度よりも低頻度でも構わないのか。
（欠損と遅延のどちらを許容するのか）


> たまにこのカウントが遅れることがあります。
画面操作（TextBox、Chart、Label 等の読み書き）を行うための Sub Received を
DataReceived のイベントから呼び出しているのが、要因の一つかと思います。

もう一度念押ししておきますが、SerialPort のイベントからの画面操作は避けてください。

画面操作が行われるのは、常にメインスレッドを基点として行われるべきです。
SerialPort のスレッドから呼びだしてはいけません。Invoke も避けましょう。


> (このときは、xy2つのデータでしたが、今は3つのデータとなっていて、
> 先頭F2-F0を検出するために、条件分岐処理で時間が掛かっているのかと考えています。)

各座標は 0000～03FF の範囲でしたよね。「3 つのデータ」というのが、
「F2,F0,x1,x2,x3,y1,y2,y3」の意味なのか
「F2,F0,x1,x2,y1,y2,z1,z3」の意味なのか
分かりにくいですが、後者の意味でしょうか。

条件分岐処理も含め、「受信時刻」の記録方法に問題がある可能性はありますが、
実際のコードが分からない以上、現時点では判断できません。

BytesToRead が返してきた値未満のサイズしか Read していなかったとすれば、
次のデータが届く（DataReceived が発生する）までの間、データの読み取りが
その分遅れる事になるわけですが、その点も考慮した設計になっているかを
再確認してみてはいかがでしょう。


> このようにしています。
SerialPort が動作するスレッドと、画面処理のスレッドは異なります。
何のために別スレッドになっているのかを念頭において設計しましょう。

今の実装は『逐次』処理になってしまっているように見うけます。
データを受信するたびに画面に表示する形にしてしまうと、
描画完了まで次の受信が遅れることになります。
それが今回の要因であるかどうかは別として。