একটি ডিভাইসের পারফরম্যান্স মূল্যায়ন করতে সিম্পলপার্ফ (Simpleperf) ব্যবহার করুন। সিম্পলপার্ফ হলো অ্যান্ড্রয়েডের অ্যাপ এবং নেটিভ প্রসেস উভয়ের জন্য একটি নেটিভ প্রোফাইলিং টুল। রিয়েল টাইমে অ্যাপের সিপিইউ ব্যবহার এবং থ্রেড অ্যাক্টিভিটি পরীক্ষা করতে সিপিইউ প্রোফাইলার (CPU Profiler) ব্যবহার করুন।
কর্মক্ষমতার দুটি দৃশ্যমান সূচক রয়েছে:
- অনুমানযোগ্য, সুস্পষ্ট পারফরম্যান্স । ইউজার ইন্টারফেস (UI) কি ফ্রেম ড্রপ করে, নাকি ধারাবাহিকভাবে ৬০ FPS-এ রেন্ডার হয়? অডিও কি কোনো আর্টিফ্যাক্ট বা পপিং ছাড়াই প্লে হয়? ব্যবহারকারীর স্ক্রিনে স্পর্শ করার পর ডিসপ্লেতে ইফেক্টটি প্রদর্শিত হতে কতক্ষণ সময় লাগে?
- দীর্ঘ সময় ধরে চলা কোনো কাজের (যেমন অ্যাপ খোলা) জন্য প্রয়োজনীয় সময় ।
প্রথমটি দ্বিতীয়টির চেয়ে বেশি লক্ষণীয়। ব্যবহারকারীরা সাধারণত জ্যাঙ্ক লক্ষ্য করেন, কিন্তু দুটি ডিভাইস পাশাপাশি না দেখলে তারা ৫০০ মিলিসেকেন্ড বনাম ৬০০ মিলিসেকেন্ড অ্যাপ চালু হওয়ার সময়ের পার্থক্য বলতে পারবেন না। টাচ ল্যাটেন্সি তাৎক্ষণিকভাবে লক্ষণীয় এবং এটি একটি ডিভাইস সম্পর্কে ধারণায় উল্লেখযোগ্যভাবে অবদান রাখে।
ফলস্বরূপ, একটি দ্রুত ডিভাইসে, UI পাইপলাইনকে কার্যকর রাখার জন্য যা যা প্রয়োজন, তা বাদে সিস্টেমের সবচেয়ে গুরুত্বপূর্ণ বিষয় হলো UI পাইপলাইন। এর মানে হলো, সাবলীল UI-এর জন্য অপ্রয়োজনীয় অন্য যেকোনো কাজ UI পাইপলাইনের দ্বারা সম্পন্ন হওয়া উচিত। একটি সাবলীল UI বজায় রাখার জন্য, যদি UI-এর কাজ চালানো যায়, তবে ব্যাকগ্রাউন্ড সিঙ্কিং, নোটিফিকেশন ডেলিভারি এবং এই জাতীয় সমস্ত কাজ বিলম্বিত করতে হবে। একটি সাবলীল UI বজায় রাখার জন্য দীর্ঘ অপারেশনগুলোর (যেমন HDR+ রানটাইম, অ্যাপ স্টার্টআপ ইত্যাদি) পারফরম্যান্সের সাথে আপোস করা গ্রহণযোগ্য।
ধারণক্ষমতা বনাম জিটার
ডিভাইসের পারফরম্যান্স বিবেচনা করার সময়, ক্যাপাসিটি এবং জিটার হলো দুটি অর্থপূর্ণ মেট্রিক।
ধারণক্ষমতা
ধারণক্ষমতা হলো কোনো একটি নির্দিষ্ট সময় ধরে ডিভাইসটির কাছে থাকা কোনো রিসোর্সের মোট পরিমাণ। এটি সিপিইউ রিসোর্স, জিপিইউ রিসোর্স, আই/ও রিসোর্স, নেটওয়ার্ক রিসোর্স, মেমরি ব্যান্ডউইথ বা এই জাতীয় যেকোনো পরিমাপ হতে পারে। পুরো সিস্টেমের পারফরম্যান্স পরীক্ষা করার সময়, স্বতন্ত্র উপাদানগুলোকে আলাদা করে একটি একক পরিমাপ ধরে নেওয়া সহায়ক হতে পারে যা পারফরম্যান্স নির্ধারণ করে (বিশেষ করে যখন একটি নতুন ডিভাইস টিউন করা হয়, কারণ সেই ডিভাইসে চালিত ওয়ার্কলোডগুলো সম্ভবত নির্দিষ্ট থাকে)।
একটি সিস্টেমের ক্ষমতা তার অনলাইন কম্পিউটিং রিসোর্সের উপর ভিত্তি করে পরিবর্তিত হয়। ক্ষমতা পরিবর্তনের প্রধান উপায় হলো সিপিইউ/জিপিইউ ফ্রিকোয়েন্সি পরিবর্তন করা, তবে সিপিইউ কোরের সংখ্যা পরিবর্তনের মতো অন্যান্য উপায়ও রয়েছে। একইভাবে, একটি সিস্টেমের ক্ষমতা তার বিদ্যুৎ খরচের সাথে সম্পর্কিত; ক্ষমতা পরিবর্তনের ফলে বিদ্যুৎ খরচেও অনুরূপ পরিবর্তন আসে।
একটি নির্দিষ্ট সময়ে প্রয়োজনীয় ক্ষমতা মূলত চলমান অ্যাপ দ্বারাই নির্ধারিত হয়। ফলে, কোনো নির্দিষ্ট ওয়ার্কলোডের জন্য প্রয়োজনীয় ক্ষমতা সমন্বয় করতে প্ল্যাটফর্মের তেমন কিছু করার থাকে না, এবং তা করার উপায়গুলো রানটাইম উন্নয়নের (অ্যান্ড্রয়েড ফ্রেমওয়ার্ক, ART, Bionic, GPU কম্পাইলার/ড্রাইভার, কার্নেল) মধ্যেই সীমাবদ্ধ।
জিটার
কোনো ওয়ার্কলোডের জন্য প্রয়োজনীয় ক্ষমতা সহজেই বোঝা গেলেও, জিটার একটি অপেক্ষাকৃত অস্পষ্ট ধারণা। দ্রুতগতির সিস্টেমের প্রতিবন্ধক হিসেবে জিটার সম্পর্কে একটি ভালো ধারণা পেতে, আমরা ‘The Case of the Missing Supercomputer Performance: Achieving Optimal Performance on the 8,192 processors of ASCI Q’ শীর্ষক গবেষণাপত্রটি পড়ার সুপারিশ করছি। (এটি ASCI Q সুপারকম্পিউটার কেন তার প্রত্যাশিত পারফরম্যান্স অর্জন করতে পারেনি তার একটি অনুসন্ধান এবং বৃহৎ সিস্টেম অপটিমাইজ করার জন্য এটি একটি চমৎকার ভূমিকা।)
এই পৃষ্ঠায় জিটার শব্দটি ব্যবহার করা হয়েছে, যা ASCI Q পেপারে নয়েজ বা কোলাহল হিসেবে উল্লেখ করা হয়েছে। জিটার হলো সিস্টেমের এমন এক এলোমেলো আচরণ যা কোনো দৃশ্যমান কাজ চলতে বাধা দেয়। এটি প্রায়শই এমন কাজ যা চালানো আবশ্যক, কিন্তু এর কোনো কঠোর সময়সীমার বাধ্যবাধকতা নাও থাকতে পারে যা এটিকে কোনো নির্দিষ্ট সময়ে চলতে বাধ্য করে। যেহেতু এটি এলোমেলো, তাই কোনো নির্দিষ্ট ওয়ার্কলোডের জন্য জিটারের অস্তিত্বকে ভুল প্রমাণ করা অত্যন্ত কঠিন। একইভাবে, কোনো নির্দিষ্ট পারফরম্যান্স সমস্যার কারণ হিসেবে জিটারের কোনো পরিচিত উৎসকে প্রমাণ করাও অত্যন্ত কঠিন। জিটারের কারণ নির্ণয়ের জন্য সবচেয়ে বেশি ব্যবহৃত টুলগুলো (যেমন ট্রেসিং বা লগিং) তাদের নিজস্ব জিটার তৈরি করতে পারে।
অ্যান্ড্রয়েডের বাস্তব প্রয়োগে যেসব জিটার দেখা যায়, তার উৎসগুলো হলো:
- শিডিউলারের বিলম্ব
- বাধা পরিচালনাকারী
- প্রিএম্পশন বা ইন্টারাপ্ট নিষ্ক্রিয় থাকা অবস্থায় ড্রাইভার কোড অনেকক্ষণ ধরে চলছে
- দীর্ঘস্থায়ী সফটআইআরকিউ
- লক বিরোধ (অ্যাপ, ফ্রেমওয়ার্ক, কার্নেল ড্রাইভার, বাইন্ডার লক, এমম্যাপ লক)
- ফাইল ডেসক্রিপ্টর কনটেনশন হলো এমন একটি পরিস্থিতি যেখানে একটি নিম্ন-অগ্রাধিকারের থ্রেড কোনো ফাইলের উপর লক ধরে রাখে, যা একটি উচ্চ-অগ্রাধিকারের থ্রেডকে চলতে বাধা দেয়।
- ওয়ার্ককিউতে UI-গুরুত্বপূর্ণ কোড চালানো হচ্ছে, যেখানে এটি বিলম্বিত হতে পারত।
- সিপিইউ নিষ্ক্রিয় রূপান্তর
- লগিং
- ইনপুট/আউটপুট বিলম্ব
- অপ্রয়োজনীয় প্রসেস তৈরি (উদাহরণস্বরূপ,
CONNECTIVITY_CHANGEব্রডকাস্ট) - অপর্যাপ্ত খালি মেমরির কারণে পেজ ক্যাশে থ্র্যাশিং হচ্ছে
ক্ষমতা বাড়ার সাথে সাথে একটি নির্দিষ্ট জিটার পিরিয়ডের জন্য প্রয়োজনীয় সময় কমতে পারে বা নাও কমতে পারে। উদাহরণস্বরূপ, যদি কোনো ড্রাইভার একটি i2c বাস থেকে রিডের জন্য অপেক্ষা করার সময় ইন্টারাপ্ট নিষ্ক্রিয় রাখে, তবে সিপিইউ ৩৮৪ মেগাহার্টজ বা ২ গিগাহার্টজে চলুক না কেন, এতে একটি নির্দিষ্ট পরিমাণ সময় লাগবে। জিটার জড়িত থাকলে পারফরম্যান্স উন্নত করার জন্য ক্ষমতা বৃদ্ধি করা কোনো কার্যকর সমাধান নয়। ফলস্বরূপ, জিটার-সীমাবদ্ধ পরিস্থিতিতে দ্রুততর প্রসেসর সাধারণত পারফরম্যান্স উন্নত করে না।
অবশেষে, ক্যাপাসিটির বিপরীতে, জিটার প্রায় সম্পূর্ণরূপে সিস্টেম বিক্রেতার এখতিয়ারভুক্ত।
মেমরি খরচ
দুর্বল পারফরম্যান্সের জন্য ঐতিহ্যগতভাবে মেমোরি খরচকে দায়ী করা হয়। যদিও মেমোরি খরচ নিজে কোনো পারফরম্যান্স সমস্যা নয়, তবে এটি lowmemorykiller ওভারহেড, সার্ভিস রিস্টার্ট এবং পেজ ক্যাশ থ্র্যাশিং-এর মাধ্যমে জিটার (jitter) সৃষ্টি করতে পারে। মেমোরি খরচ কমালে দুর্বল পারফরম্যান্সের সরাসরি কারণগুলো এড়ানো সম্ভব, তবে এমন কিছু নির্দিষ্ট উন্নতিও থাকতে পারে যা সেই কারণগুলো এড়াতে পারে (উদাহরণস্বরূপ, ফ্রেমওয়ার্কটিকে পিন করা, যাতে শীঘ্রই পেজ-ইন হওয়ার ঠিক আগে এটি পেজ-আউট না হয়ে যায়)।
প্রাথমিক ডিভাইসের কর্মক্ষমতা বিশ্লেষণ করুন
একটি কার্যকরী কিন্তু দুর্বল পারফরম্যান্সযুক্ত সিস্টেম থেকে শুরু করে, ব্যবহারকারীর কাছে দৃশ্যমান দুর্বল পারফরম্যান্সের স্বতন্ত্র ঘটনাগুলো খতিয়ে দেখে সিস্টেমটির আচরণ ঠিক করার চেষ্টা করা কোনো সঠিক কৌশল নয় । যেহেতু দুর্বল পারফরম্যান্স সাধারণত সহজে পুনরুৎপাদনযোগ্য নয় (অর্থাৎ, জিটার) বা এটি কোনো অ্যাপের সমস্যাও নয়, তাই সম্পূর্ণ সিস্টেমের অসংখ্য পরিবর্তনশীল উপাদান এই কৌশলটিকে কার্যকর হতে বাধা দেয়। ফলস্বরূপ, কারণগুলো ভুলভাবে চিহ্নিত করা এবং সামান্য উন্নতি করার সম্ভাবনা খুব বেশি থাকে, এবং এর ফলে পুরো সিস্টেম জুড়ে পারফরম্যান্স ঠিক করার পদ্ধতিগত সুযোগগুলো হাতছাড়া হয়ে যায়।
এর পরিবর্তে, নতুন ডিভাইস চালু করার সময় নিম্নলিখিত সাধারণ পদ্ধতিটি ব্যবহার করুন:
- সমস্ত ড্রাইভার চালু থাকা অবস্থায় এবং কিছু প্রাথমিক ফ্রিকোয়েন্সি গভর্নর সেটিংস সহ সিস্টেমটিকে UI-তে বুট করান (যদি আপনি ফ্রিকোয়েন্সি গভর্নর সেটিংস পরিবর্তন করেন, তবে নীচের সমস্ত ধাপগুলি আবার অনুসরণ করুন)।
- নিশ্চিত করুন যে কার্নেল
sched_blocked_reasonট্রেসপয়েন্টের পাশাপাশি ডিসপ্লে পাইপলাইনের অন্যান্য ট্রেসপয়েন্টগুলোকেও সমর্থন করে, যেগুলো নির্দেশ করে কখন ফ্রেমটি ডিসপ্লেতে পৌঁছে দেওয়া হয়। - একটি হালকা ও সামঞ্জস্যপূর্ণ ওয়ার্কলোড (যেমন, UiBench বা TouchLatency-এর বল টেস্ট) চালানোর সময় সম্পূর্ণ UI পাইপলাইনের (IRQ-এর মাধ্যমে ইনপুট গ্রহণ থেকে শুরু করে চূড়ান্ত স্ক্যানআউট পর্যন্ত) দীর্ঘ ট্রেস নিন।
- লাইটওয়েট এবং কনসিস্টেন্ট ওয়ার্কলোডে শনাক্ত হওয়া ফ্রেম ড্রপগুলো ঠিক করুন।
- ধাপ ৩-৪ পুনরাবৃত্তি করুন যতক্ষণ না আপনি একবারে ২০ সেকেন্ডের বেশি সময় ধরে কোনো ফ্রেম ড্রপ ছাড়াই চালাতে পারেন।
- জ্যাঙ্কের অন্যান্য ব্যবহারকারী-দৃশ্যমান উৎসগুলিতে যান।
ডিভাইস চালু করার একেবারে শুরুতে আপনি আরও কিছু সহজ কাজ করতে পারেন, যেমন:
- আপনার কার্নেলে sched_blocked_reason ট্রেসপয়েন্ট প্যাচটি আছে কিনা তা নিশ্চিত করুন। এই ট্রেসপয়েন্টটি সিস্ট্রেস (systrace)-এর sched ট্রেস ক্যাটাগরির মাধ্যমে সক্রিয় করা হয় এবং যখন কোনো থ্রেড নিরবচ্ছিন্ন স্লিপে (uninterruptible sleep) প্রবেশ করে, তখন সেই থ্রেডকে স্লিপ করানোর জন্য দায়ী ফাংশনটি সরবরাহ করে। পারফরম্যান্স বিশ্লেষণের জন্য এটি অত্যন্ত গুরুত্বপূর্ণ, কারণ নিরবচ্ছিন্ন স্লিপ হলো জিটার (jitter)-এর একটি খুব সাধারণ সূচক।
- জিপিইউ এবং ডিসপ্লে পাইপলাইনের জন্য আপনার পর্যাপ্ত ট্রেসিং ব্যবস্থা আছে কিনা তা নিশ্চিত করুন। সাম্প্রতিক কোয়ালকম এসওসি-গুলিতে, নিম্নলিখিত পদ্ধতি ব্যবহার করে ট্রেসপয়েন্ট সক্রিয় করা হয়:
adb shell "echo 1 > /d/tracing/events/kgsl/enable"adb shell "echo 1 > /d/tracing/events/mdss/enable"
আপনি যখন সিস্ট্রেস (systrace) চালান, তখনও এই ইভেন্টগুলি সক্রিয় থাকে, ফলে আপনি ট্রেসের mdss_fb0 সেকশনে ডিসপ্লে পাইপলাইন (MDSS) সম্পর্কে অতিরিক্ত তথ্য দেখতে পারেন। কোয়ালকম এসওসি (Qualcomm SOC)-গুলিতে, আপনি স্ট্যান্ডার্ড সিস্ট্রেস ভিউতে জিপিইউ (GPU) সম্পর্কে কোনো অতিরিক্ত তথ্য দেখতে পাবেন না, কিন্তু ফলাফলগুলি ট্রেসের মধ্যেই উপস্থিত থাকে (বিস্তারিত জানতে, ‘আন্ডারস্ট্যান্ডিং সিস্ট্রেস’ দেখুন)।
এই ধরনের ডিসপ্লে ট্রেসিং থেকে আপনার যা প্রয়োজন তা হলো একটি একক ইভেন্ট, যা সরাসরি নির্দেশ করে যে একটি ফ্রেম ডিসপ্লেতে পৌঁছে গেছে। সেখান থেকে, আপনি নির্ধারণ করতে পারবেন যে আপনি সফলভাবে আপনার ফ্রেম টাইম অর্জন করেছেন কিনা; যদি ইভেন্ট Xn, ইভেন্ট Xn -1 এর ১৬.৭ মিলিসেকেন্ডেরও কম সময়ে ঘটে (একটি ৬০ হার্জ ডিসপ্লে ধরে নিলে), তাহলে আপনি বুঝবেন যে আপনার ডিসপ্লেতে কোনো জ্যাঙ্ক হয়নি। যদি আপনার এসওসি (SOC) এই ধরনের সিগন্যাল সরবরাহ না করে, তবে সেগুলি পাওয়ার জন্য আপনার ভেন্ডরের সাথে কাজ করুন। ফ্রেম সম্পূর্ণ হওয়ার একটি সুনির্দিষ্ট সংকেত ছাড়া জিটার ডিবাগ করা অত্যন্ত কঠিন।
সিন্থেটিক বেঞ্চমার্ক ব্যবহার করুন
কোনো ডিভাইসের মৌলিক কার্যকারিতা নিশ্চিত করার জন্য সিন্থেটিক বেঞ্চমার্কগুলো উপযোগী। তবে, ডিভাইসের অনুভূত পারফরম্যান্সের বিকল্প হিসেবে বেঞ্চমার্ককে বিবেচনা করা কার্যকর নয়।
SOC-এর অভিজ্ঞতা থেকে দেখা যায় যে, বিভিন্ন SOC-এর সিন্থেটিক বেঞ্চমার্ক পারফরম্যান্সের পার্থক্যের সাথে দৃশ্যমান UI পারফরম্যান্সের (যেমন ড্রপ হওয়া ফ্রেমের সংখ্যা, ৯৯তম পার্সেন্টাইল ফ্রেম টাইম ইত্যাদি) অনুরূপ কোনো সম্পর্ক নেই। সিন্থেটিক বেঞ্চমার্কগুলো শুধুমাত্র ধারণক্ষমতা-ভিত্তিক বেঞ্চমার্ক; জিটার এই বেঞ্চমার্কগুলোর পরিমাপকৃত পারফরম্যান্সকে কেবল বেঞ্চমার্কের মূল কার্যক্রম থেকে সময় কেড়ে নিয়েই প্রভাবিত করে। ফলে, ব্যবহারকারীর কাছে অনুভূত পারফরম্যান্সের পরিমাপক হিসেবে সিন্থেটিক বেঞ্চমার্ক স্কোর বেশিরভাগ ক্ষেত্রেই অপ্রাসঙ্গিক।
দুটি SOC-এর কথা ভাবুন যেগুলো Benchmark X চালাচ্ছে, যা ১০০০ ফ্রেমের UI রেন্ডার করে এবং মোট রেন্ডারিং সময় রিপোর্ট করে (কম স্কোর ভালো)।
- SOC 1 বেঞ্চমার্ক X-এর প্রতিটি ফ্রেম ১০ মিলিসেকেন্ডে রেন্ডার করে এবং ১০,০০০ স্কোর করে।
- SOC 2 ১ মিলিসেকেন্ডে ৯৯% ফ্রেম এবং ১০০ মিলিসেকেন্ডে মাত্র ১% ফ্রেম রেন্ডার করে ১৯,৯০০ স্কোর অর্জন করেছে, যা আগের চেয়ে অনেক ভালো একটি স্কোর।
যদি বেঞ্চমার্কটি প্রকৃত UI পারফরম্যান্সের নির্দেশক হয়, তাহলে SOC 2 ব্যবহারযোগ্য থাকবে না। ৬০ Hz রিফ্রেশ রেট ধরে নিলে, SOC 2-এর প্রতি ১.৫ সেকেন্ড অপারেশনে একটি করে ফ্রেম জ্যাঙ্কি বা ঝাঁকুনিপূর্ণ হবে। অপরদিকে, SOC 1 (বেঞ্চমার্ক X অনুযায়ী ধীরগতির SOC) পুরোপুরি সাবলীলভাবে চলবে।
বাগ রিপোর্ট ব্যবহার করুন
বাগ রিপোর্ট কখনও কখনও পারফরম্যান্স বিশ্লেষণের জন্য উপযোগী, কিন্তু এগুলি আকারে বেশ বড় হওয়ায় বিক্ষিপ্ত জ্যাঙ্ক সমস্যা ডিবাগ করার জন্য খুব কমই কার্যকর। এগুলি একটি নির্দিষ্ট সময়ে সিস্টেম কী করছিল সে সম্পর্কে কিছু ইঙ্গিত দিতে পারে, বিশেষ করে যদি জ্যাঙ্কটি কোনো অ্যাপ ট্রানজিশনের সময় ঘটে থাকে (যা একটি বাগ রিপোর্টে নথিভুক্ত করা হয়)। বাগ রিপোর্টগুলি সিস্টেমের কোনো বড় ধরনের সমস্যারও ইঙ্গিত দিতে পারে, যা এর কার্যকর ক্ষমতা কমিয়ে দিতে পারে (যেমন থার্মাল থ্রটলিং বা মেমরি ফ্র্যাগমেন্টেশন)।
টাচলেটেন্সি ব্যবহার করুন
টাচলেটেন্সি (TouchLatency) থেকে বেশ কিছু ত্রুটিপূর্ণ আচরণের উদাহরণ পাওয়া যায়, যা পিক্সেল এবং পিক্সেল এক্সএল-এর জন্য ব্যবহৃত পছন্দের পর্যায়ক্রমিক ওয়ার্কলোড। এটি frameworks/base/tests/TouchLatency তে পাওয়া যায় এবং এর দুটি মোড রয়েছে: টাচ ল্যাটেন্সি এবং বাউন্সিং বল (মোড পরিবর্তন করতে উপরের-ডান কোণার বোতামটিতে ক্লিক করুন)।
বাউন্সিং বল টেস্টটি দেখতে যতটা সহজ, ঠিক ততটাই সহজ: ব্যবহারকারীর ইনপুট নির্বিশেষে একটি বল স্ক্রিনে অনন্তকাল ধরে লাফাতে থাকে। সাধারণত নিখুঁতভাবে চালানো এটিই সবচেয়ে কঠিন পরীক্ষা, কিন্তু কোনো ফ্রেম ড্রপ ছাড়াই এটি যত ভালোভাবে চলতে পারবে, আপনার ডিভাইসটি তত ভালো হবে। বাউন্সিং বল টেস্টটি কঠিন কারণ এটি একটি সাধারণ কিন্তু পুরোপুরি সামঞ্জস্যপূর্ণ ওয়ার্কলোড যা খুব কম ক্লকে চলে (এটি ধরে নেওয়া হচ্ছে যে ডিভাইসটিতে একটি ফ্রিকোয়েন্সি গভর্নর আছে; যদি ডিভাইসটি ফিক্সড ক্লকে চলে, তবে প্রথমবার বাউন্সিং বল টেস্ট চালানোর সময় CPU/GPU-কে প্রায় সর্বনিম্ন পর্যায়ে ডাউনক্লক করুন)। সিস্টেম যখন স্থির হয়ে যায় এবং ক্লক স্পিড আইডল অবস্থার কাছাকাছি নেমে আসে, তখন প্রতি ফ্রেমে প্রয়োজনীয় CPU/GPU সময় বেড়ে যায়। আপনি বলটির দিকে তাকিয়ে বিভিন্ন জিনিস জ্যাঙ্ক করতে দেখবেন এবং সিস্ট্রেস-এও মিস হওয়া ফ্রেম দেখতে পাবেন।
যেহেতু ওয়ার্কলোড বেশ সামঞ্জস্যপূর্ণ, তাই UI পাইপলাইনের পরিবর্তে প্রতিটি মিস হওয়া ফ্রেমের সময় সিস্টেমে ঠিক কী চলছে তা ট্র্যাক করার মাধ্যমে, ব্যবহারকারীর কাছে দৃশ্যমান বেশিরভাগ ওয়ার্কলোডের তুলনায় জিটারের অধিকাংশ উৎস অনেক সহজে শনাক্ত করা যায় । কম ক্লক স্পিড জিটারের প্রভাবকে বাড়িয়ে তোলে, কারণ এর ফলে যেকোনো জিটারের কারণে ফ্রেম ড্রপ হওয়ার সম্ভাবনা বেড়ে যায়। ফলস্বরূপ, TouchLatency যত 60FPS-এর কাছাকাছি থাকবে, বড় অ্যাপগুলিতে বিক্ষিপ্ত এবং সহজে পুনরুৎপাদন করা যায় না এমন জ্যাঙ্ক সৃষ্টিকারী সিস্টেমের অস্বাভাবিক আচরণের সম্ভাবনা তত কম থাকবে।
যেহেতু জিটার প্রায়শই (কিন্তু সবসময় নয়) ক্লকস্পিড-অপরিবর্তনীয়, তাই নিম্নলিখিত কারণগুলোর জন্য জিটার নির্ণয় করতে খুব কম ক্লকে চালিত একটি পরীক্ষা ব্যবহার করুন:
- সব জিটারই ক্লকস্পিড-অপরিবর্তনীয় নয়; এর অনেক উৎসই কেবল সিপিইউ-এর সময় খরচ করে।
- গভর্নরের উচিত ক্লকিং ডাউন করে গড় ফ্রেম টাইমকে ডেডলাইনের কাছাকাছি নিয়ে আসা, তাই UI-বহির্ভূত কাজ চালাতে ব্যয় হওয়া সময় এটিকে এমন এক পর্যায়ে নিয়ে যেতে পারে যেখানে একটি ফ্রেম ড্রপ হয়।